GCC is broken

[Geri]

actually, different compilers usually implement a lot of things in wrong order. ) (-s are good to have in all codes.

[sortie]

geri: Operator precedence is well-defined by the C and C++ standards (and any other standard for other programming languages). If a compiler is unable to deal properly with the standard operator precedence, then that compiler is trash. Handling operator precedence when parsing is one of the first things you learn in a compiler course - the hardest part is potentially just looking it up in the standard if it is poorly written (good standards include a formal grammar describing how to parse the language).

[Geri]

sortie: then gcc is a trash, becouse i usually have issues with it when i update the compiler to newer version

[sortie]

No, your code is likely broken. Optimizations and compiler upgrades usually reveal C programmer mistakes rather than actual compiler flaws (barring the occasional compiler bug, but they are considerably less common than breaking due to bad code). If your code relies on undefined behaviour, the code was broken before the compiler upgrade, it just happened to reveal the bugs. I've made sure my operating system has no undefined behaviour (to the best of my efforts, I'm building all code the undefined behaviour sanitizer of gcc 4.9) and the compiler upgrades I've done recently (gcc 4.6.2, gcc 4.6.3, gcc 4.8-rc1, gcc 4.8.0, gcc 4.8.1, gcc 4.8.2, gcc 4.9-rc1, gcc 4.9.0) have all been with none to minor problems (that were all my fault, not the compiler's). The only big issue I've had was gcc 4.7.x breaking my operating system, but that was because I relied on undefined behaviour. (Although, I don't know if it historically has been the case that major gcc releases had bad compiler bugs, but every compiler release usually break some poorly written software and that's okay).

[Geri]

well yeah, some gcc versions even mistake the endianness, but my code is broken.

gcc and other compilers are perfect. who questions this, is broken. everything is broken, but you, and the compilers are perfect.
even if some of them is trash. but they are perfect. everybody spreading lies, except me. the poorly written sofSEGMENTATION FAULT in sortie/brain.c at line 1751

[Combuster]

some gcc versions even mistake the endianness

Well then, give us a demonstration. Otherwise I'll simply have to believe my own observations and the million other people that do trust the compiler on this.

[Geri]

http://nehe.gamedev.net/tutorial/loadin ... 27s/22001/

the gcc in devc gave me rgb colors swapped compared to suse linux 10.1 (and the gcc in it) with this practicular code depending what optimization level was enabled.



now give me demonstration about the one million people who trust in this compiler.

[Geri]

https://www.google.hu/search?q=i+trust+ ... S:official

4 result... wow... a bit smalller than a million


https://www.google.hu/search?q=%22i+tru ... 8gfg94HoCw

0 result :d

https://www.google.hu/search?q=%22i+tru ... S:official

[Geri]

actually, this topic is started from here ( http://forum.osdev.org/viewtopic.php?f=2&t=27298 ) and split by the moderator.

the post i answered on, was this:

@stlw: Stop spreading lies and look up operator precedence. Everytime you are in doubt, you should look it up, instead of randomly adding unnecessary parentheses. This improves both your code and your coding skills considerably.

The & and | operators are quite loose while << is considerably tighter. For reference, see http://en.cppreference.com/w/cpp/langua ... precedence. That is, his code does do what is intended in this case.

The main culprit is likely silent promotion to 'int' and the fact that he appears to use uint16_t instead of size_t - or just that his code is so mistaken in the first place that it doesn't work because of something else bad he did.

[Geri]

and also, i dont think gcc is broken becouse of that.
all other compiler crap out in situations like this in different ways.

sortie sayd that these compilers are ,,trash'', not me

[sortie]

SEGMENTATION FAULT in sortie/brain.c at line 1751

I don't have segmentation faults. I have assertion failures.

well yeah, some gcc versions even mistake the endianness, but my code is broken.

Very likely your code is broken. Note that the NeHe code you linked to is trash and doesn't even handle the endianness correctly (that is, not at all but just freads it into a structure). (It doesn't even handle fixed-width integers correctly and assumes things about the size of GLuint. Its `optimize byte swapping' in LoadUncompressedTGA is a joke. Lots of WTFs here, at least in the Linux port source code I downloaded.) Note that you should follow modern tutorials such as http://open.gl/ for real OpenGL programming rather than the loads of deprecated and useless tutorials out there.

I'll admit I didn't look the full source code through and located the UB in question, but it was obviously code of poor quality and it did raw X11 calls (at least in the download I got). Your rendering toolkit likely used another endianness for the screen buffers or something. You didn't give me enough information to confirm the issue and I doubt its existence.

It's insanity to assume a broken compiler when coding. I'm not saying you should trust the compiler, but the code should trust the compiler, otherwise the code is meaningless. Rather than trying to be robust in an environment where the compiler may be wrong, you should write your code correctly, and make sure that compiler bugs are even more explosive - and then fixing the compiler errors instead! These issues do exist, check the GCC bug tracker if you need to prove it, which there is no need to. My statement is not their absence, but most issues that are triggered by compiler upgrades are caused by bad programming (undefined behavior) and not actual compiler bugs (even if it would appear this way to unskilled programmers).

Please, what the ****? Why are you inserting images of ponies and demonstrating your statements by showing how many Google hits you get for particular phrases? I'll assure that reality is very poorly correlated with those. Posts like that are more likely to get yourself banned for poor behavior than actually uncovering truth and convincing anyone. You do know you can edit posts, right? Instead of double- nay, posting four times in a row while I type this?

I do still stand by my statement that compilers that get operator precedence wrong are trash. None of the major C compilers I know of have the problem. Any such issues you perceived were either very critical compiler bugs (which I doubt, as that would break most software if the operator precedence suddenly changed) - or you are wrong: Problems related to undefined behavior, triggered by a compiler upgrade, are often quite mysterious and unaware developers will blame their tools rather than their code.

[Geri]

ok, then lets forget about the nehe code:

https://www.google.hu/search?q=gcc+prec ... 8gfI5oGQDg

5 million result. so you still say compilers with these bugs are trash? poor gcc.

[Owen]

ok, then lets forget about the nehe code:

https://www.google.hu/search?q=gcc+prec ... 8gfI5oGQDg

5 million result. so you still say compilers with these bugs are trash? poor gcc.

So, I looked at all of the ones which linked to the GCC bug tracker.

One of them was a bug in a test (the test assumed wrong precedence, always passed, oops).

The rest are all duplicates of the same bug, "RESOLVED INVALID", because they're all people failing to understand operator precedence and/or undefined behavior.

As for the previously mentioned code... the "endian swapping code" is an example of undefined behavior of the trivial kind.

[sortie]

I also looked through the gcc bug reports on the first page of the google results:

• Bug 7135 (the code had undefined behavior and was not a compiler bug),
• Bug 17507 (the code had undefined behavior and was not a compiler bug),
• Bug 15103 (the code had undefined behavior and was not a compiler bug),
• Bug 40960 (unrelated, was about command line parsing),
• Bug 46274 (this was a real bug, but doesn't count as it happened during the gcc 4.6.0 development and was not in any actual release),
• Bug 18047 (this was a real bug, but doesn't count as it happened during the gcc 4.0.0 development and was not in any actual release).

As such, none of those bugs were valid and actually affected a released version of gcc, and almost all of them were over 10 years old. The gcc 4.6.0 bug is the only one I could see in modern history and that appears to have happened during development (where regressions do happen), but it was fixed in time for the real release as a priority 3 bug.

You seem to think there is any significance to the amount of google results. There is not, unless you are an internet cartoonist making funny useless statistics.

[Geri]

owen: lie. on the first page, there is a solved precedence bug. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18047
,,Fixed by the above patch.''