3 ms·

The case I know of with SPEC was non-conforming code, not undefined behaviour. You really can't hold gcc responsible for bad code, though there's often a workar

• iforgotpassword 8y ago
  That's not the point. Of course you should write proper code, not do goofy things with pointers etc. But what I don't think was to excuse was that the compiler did this without warnings. And again the GCC folks' reply was "well you can crank up the warnings with -Wwhatever-the-hell". But that's just plain stupid. Any time the compiler removes code because of UB, non-conformance or specific interpretation of ambiguous specs in the C (or whatever) standard, a warning should be emitted by default, because it's pretty much guaranteed that the coder made either a blatant mistake or tried to do stuff that's simply wrong, again either by unawareness or by expecting the compiler to still emit some code that will at least work on their specific platform.
  • gnufx 8y ago
    I always advise turning on all warnings and maybe disabling them selectively, and using any static or dynamic analysis available (and understanding the warnings). Compilation time won't catch a lot of things anyhow, and most people just ignore warnings. It's a matter of judgement whether to issue specific warnings by default, but I don't want the noise from things like intentionally elided code from compile-time constants. In the case of aggressive-loop-optimizations I'd have thought the argument would be whether it should be on by default, or at something like -O2. [On my first workhorse systems, reading past the end of an array, as in the SPEC case, gave a hardware error if you didn't disable that.] Incidentally, ifort turns on (or used to) generally-invalid optimizations without warning, which GCC doesn't, and the first question to ask about user complaints of SEGVs on the systems I support is "ifort?" if only because of an optimzation which is valid but hits typical resource limits.
    • iforgotpassword 8y ago
      > I always advise turning on all warnings and maybe disabling them selectively, and using any static or dynamic analysis available I absolutely agree. I actually frequently compile with both GCC and clang as they tend to find different issues at times. Same goes for valgrind and address sanitizer. > but I don't want the noise from things like intentionally elided code from compile-time constants Not that I'm in any way familiar with GCC internals, but shouldn't it be possible to only print warnings for problematic cases, and not things like constant folding, unreachable code, redundant range checks etc. > On my first workhorse systems, reading past the end of an array, as in the SPEC case, gave a hardware error if you didn't disable that. That sounds like a better outcome than a program that runs but computes something entirely different because of a missing loop. Depending on the application, that could be a subtle bug that can go undetected for a while. Yes, the same could be true for just generating the according unsafe stream of instructions (depending on platform, mempry layout, moon phase), but I'm not even suggesting the compiler should just generate that broken code. In the past compilers did, because they weren't that elaborate yet in general. What I can't wrap my head around is this: Any such "optimization" basically breaks the program already at compile time, guaranteed. When can this possibly ever be wanted? I'm not saying it's worse than just emitting code that might or might not crash the program because it reads or writes past the end of an array. But it's not better either because the compiler already has the knowledge that your code sucks, and the GCC devs decided that instead of aborting compilation (my preference, obviously with override switch) or printing a warning (by default), they'll just render the program useless in a different way. I feel like it's just not a good choice how to handle that situation. Or maybe look at it this way: in the past, code like the SPEC example almost always compiled to something that still worked as intended. This isn't great and shouldn't be encouraged but that's just how it was. Now with the new compiler and the same compile flags suddenly everything compiles and runs seemingly fine but produces the wrong result. And the compiler perfectly knew this would happen. As for ifort, I've never even used it, but it sounds rather user hostile. In general, I still like and use GCC. I think it's good they revised some of those more aggressive optimizations, and I really like how they also improved the readability of the compiler warnings a lot, following clang.