2017-11-08 06:43:10

@Ethin, look also at the speed, and the performance of the code which is generated
this is the case!, sometimes a compiler generates junk code between the instructions while the other doesnt, or vice versa which impacts speed and performance so much

2017-11-08 17:32:50

@visualstudio, if your talking about the old compilers from like a decade ago, yeah, probably. But most of those "junk instructions," as you put it, are assembler directives or debugging information. Optimization removes most o those. Those "junk instructions" are usually also because optimization was disabled entirely and it was an error on a higher-level language.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-11-09 00:17:41

sometimes optimization doesnt remove those instructions!
sometimes a code can be generated as an undefined behaiviour in a compiler while in another compiler it will correctly be generated!

2017-11-09 00:33:12

@visualstudio, I don't know where your getting your information from. If your using VS2017, GCC, or Clang/LLVM, you should be fine. If your dumb enough to use a compiler that's old, out of date, and/or unmaintained, then of course it's going to generate bad instructions. That's obvious. But if you use the latest update of the compiler your using, or the latest your OS provides, then the likelihood in the compiler encountering a critical error or generating instructions that crash your program is literally nil. If the latest compilers that you use crash your program when they are compiled, then it's you that's made a critical error, not your compiler. Don't blame everything that makes your program crash unexpectedly on your compiler; most likely it's your code or the options you pass to the compiler, not the compiler. If I were to guess, I'd say that less than 0.2 percent of the program crashes today are compiler-based errors, and the other 99.98-99.99 percent of crashes are the error on behalf of the programmer. C++ is not going to coddle you. It's not going to be like BGT and hold your hand all the time. It's not going to guide you. If you fuck up, you fuck up, and it's not going to even tell you about it. You'll have to discover that on your own. If your going to code in C++, be prepared for headaches and difficulties, and don't expect your compiler to be nice. It's going to be mean, and it could care less what you think. When compiling programs in any language, a good rule of thumb is to never use options your not familiar with. If you stick to the options you know very well, nothing well go wrong -- except, of course, for errors in the source code of the program itself.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-11-09 07:56:46 (edited by visualstudio 2017-11-09 07:59:12)

hello,
go here he had tested a code in different compilers and gave the asm code which was generated and compaired it together
i dont say that compilers dont generate fast code, i say compilers generate crashable code sometimes (for example MSVC can generate a code that crashes the app while gcc not or vice versa) or a code that might act as an undefined behaiviour in a compiler or in another not
this is the case, compilers are incompatible in terms of abi and other asspects sometimes i'm not talking about optimization, also if you optimize, it can change your code somehow, but it doesnt remove the incompatibility
btw i'm using MSVC 2015 as my compiler and GCC 7 (in windows msvc)

2017-11-09 19:01:13

@30, this doesn't prove much. It only proves that a particular library generates crashable code. And MSVC only generates crashable code if you liberally use the __asm__() function a lot. However, we've already established that compilers generate different ABIs: MSVC generates only windows-based ABIs; GCC/Clang only generate Cygwin, Mac OS, Linux, and Unix-based ABIs (perhaps ARM, AVR32, and other architectures and OSes can be added in there too). The fact of the matter is that the likelihood of your compiler generating faulty code when you made absolutely no mistake whatsoever, whether it be logical, mathematical, syntactical, or otherwise is less than 0.01 percent. If you try and mix asm instructions from one compiler in another, of course it's not going to work, and if you try to mix different architecture-based asm instructions together, then it's definitely not going to work. But since there are very few people who are dumb enough to play with assembly language when they don't know how to program in it anyway; since the only books that teach assembly language are books from the early 2000s and late 90s; and since the only compilers that generate faulty code are really, really old one,s your point is basically moot.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-11-09 21:55:35

this is true,
but when you use x86intrin.h, immintrin.h, avxintrin.h which are for different instruction set in x86/x64 processors, in different compilers you sometimes get crashable code
i have to note that compilers are not so much intelegent to generate the best code
also you cant use instruction set for arm for example in x86, they are totally (by totally i mean completely) different in terms of registers, instructions, etc