GCC is broken

[Geri]

I also looked through the gcc bug reports on the first page of the google results:
There is not, unless you are an internet cartoonist making funny useless statistics.

i am :3

[sortie]

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.''

That was bug 18047, which I describe above. It happened over 10 years ago and was just a regression that happened in the gcc development version for a single day and was gone the next, it never made it into a release.

[Geri]

sortie: i wrote that for owen, he sayd that none of them was actual bugs, and they are duplicate of a resolved invalid.

and also, of course the beta versions counts too, there is no kind of special laws by god that putting those bugs out from this investigation, someone actually downloaded and used that compiler, he is reported its bad with his software.

[Owen]

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.''

That link isn't on the first 5 pages of the search you linked to (Problem #1 with linking to Google results: they differ for different people). Secondly, are we discussing C++ or C? This bug only affects the former (and existed during a major overhaul of the C++ compiler)

sortie: i wrote that for owen, he sayd that none of them was actual bugs, and they are duplicate of a resolved invalid.

and also, of course the beta versions counts too, there is no kind of special laws by god that putting those bugs out from this investigation, someone actually downloaded and used that compiler, he is reported its bad with his software.

A version which only existed in a source code repository for a few days is, let's be honest, not overly unexpected.

Of the bugs Sortie classified as operator precedence bugs, additionally note that the one logged against 4.6 is a bug in the test suite, not compiler.

[sortie]

sortie: i wrote that for owen, he sayd that none of them was actual bugs, and they are duplicate of a resolved invalid.

None of these count as bugs for the purpose of this discussion and proving your point. Two of them, as point out, were real bugs but as a user of gcc you would never have seen them.

and also, of course the beta versions counts too, there is no kind of special laws by god that putting those bugs out from this investigation, someone actually downloaded and used that compiler, he is reported its bad with his software.

Except that there are no beta versions of gcc. There are releases. If you use anything but releases, you void the warranty and there will be regressions (that's life), but no distribution will use such a compiler and no sane user would install such a compiler (unless they wish to help develop the compiler by reporting development regressions). What matters is not whether a regression or two sneak in during development, but whether such bugs make into a releas. That is, whether the gcc quality assurance is good enough. So far the evidence suggests that it is good enough that you can rely on operator precedence being correct. The gcc teams doesn't do beta releases, but they do occasionally make a release candidate prior to a new major release. However, those are mostly bug free with only a few remaining priority bugs that will be fixed before the real release (or during the patch releases).

[Geri]

well, somebody seen them, thats why he reported them, and thats how they fixed them. so somebody had to use them. so they were real bugs. so just dont compare these bugs to bigfoot

[sortie]

Dude, what? What is your point?

[Geri]

my point is with this whole conversation is to write code that works on first try without any problem even with dozens of versions of flawed/unflawed compilers, platforms, environments, becouse this reduces the development costs and times. to achieve this, one of the most important thing is to have manual parenthesis ewerywhere which have more operator than one.

and an another optional point is that tomoko shall have white pantsu.

[Brendan]

Hi,

• 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),

This is by far the most significant problem: GCC correctly conforms to the language's specification; but the language's specification is bad because it expects you to remember precedence rules that are neither intuitive nor obvious.


Cheers,

Brendan

[sortie]

Actually, those bugs were not due to undefined operator precedence, there we no problem in how the code should be parsed. The problem was that the expression evaluation order was undefined: What should a++ / --a do?

[Brendan]

Hi,

Actually, those bugs were not due to undefined operator precedence, there we no problem in how the code should be parsed. The problem was that the expression evaluation order was undefined: What should a++ / --a do?

Because the increment and decrement operators have side effects, they cause far more problems than they're worth and they either shouldn't have been included in the language at all or should've been statements instead of operators.

Of course this is just the tip of the iceberg - there's problems with virtually everything involved in expressions in C. We can categorise all the problems like this:

• undefined behaviour - if its behaviour is undefined then it shouldn't be used and therefore should be an error and not undefined.
• implementation defined behaviour - essentially the same as undefined behaviour, but worse because it gives programmers the illusion that it's less bad
• defined badly behaviour - this is all the "neither intuitive nor obvious" rules used that determine order of evaluation (which is more than just operator precedence alone).

For a simple example, even something like "3*4/5 == 3/5*3" is a major WTF where "real people" are required to use industrial mining equipment to smash the part of their brain responsible for logical reasoning, just so they can learn to accept it and become a "programmer".


Cheers,

Brendan

[thomasloven]

I just browsed through the discussion and haven't followed the original topic, so I'm sorry if I'm repeating something that's already been said or even misunderstand the issue completely.

If a compiler may have a bug with order of evaluation of operators, what's to stop it from having bugs in evaluation of parentheses?
Bugs are bugs and adding parentheses is not a guaranteed protection. They may however increase the readability of code. To some extent...

[Rusky]

Knowing a bit about compiler internals, it would be extremely hard to release a self-hosting compiler with a bug in its evaluation order that didn't catastrophically break everything it was tested on, which includes itself. For that matter, it would be rather tricky to write any kind of expression parser that accidentally messed up parentheses.

[alexfru]

Parentheses, unlikely, right. Though, given the complexity of the modern compiler, you can never be sure it has no bugs. I expect the code generator/optimizer to be the worst offender here since parsing is limited and trivial on the grand scale.

[Love4Boobies]

Heh, my post got removed, probably because of the Spiderman image (seriously?). Anyway, I had mentioned to alexfru formal verification as a way to guarantee bug-free code, as long as the specification accurately describes the product you want to create but that it's more trouble than it's worth for most projects.