3 ms·

So this article says that optimizing compilers are unreliable? I don't think this is the case. Compiler bugs are pretty rare, a bigger problem are insane langu

So this article says that optimizing compilers are unreliable? I don't think this is the case. Compiler bugs are pretty rare, a bigger problem are insane language standards that have undefined behaviour lingering behind every corner.

randomsearch 11y ago
Compiler bugs are not rare, quite the opposite, and this is often because of premature optimisation. For example, GPGPU compilers are awful: http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2015/PLDI_Fuzzing.pdf http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2015/PLDI...
- DannyBee 11y ago
  It's more that compiler vendors who compete mainly on the basis of worthless benchmarks do awful things. This is one of the reasons gcc/llvm won: they don't care about that stuff. I mean, they care about performance, but not at all costs like these guys care. At some point, people wanted compilers that did less stupid things. So they moved to the vendors who did that. The reason it's so awful in the GPGPU space is because none of these vendors produce compilers yet. Instead, the vendors you have are those whose main goal in life is to generate better performance numbers than the other guy. Ask anyone about the old days of fortran compilers and early optimizing C compilers and what have you. What exists now is essentially "what happened after the market pushed back". Sadly, it didn't go as far as some people want (in either direction).
  - loup-vaillant 11y ago
    > This is one of the reasons gcc/llvm won: they don't care about that stuff. I mean, they care about performance, but not at all costs like these guys care. Really? http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201... https://news.ycombinator.com/item?id=11219874 https://news.ycombinator.com/item?id=11219874 While GCC and LLVM do care about implementing the standard correctly, they show little mercy to the poor developer who failed to avoid one of the many sharp corners of undefined behaviour.
    - DannyBee 11y ago
      Yes. Really. There was a long thread about this just a few days ago (https://news.ycombinator.com/item?id=11219874 https://news.ycombinator.com/item?id=11219874) I already commented there, and since i didn't always have pleasant things to say, i'm not going to repeat them here.
MichaelBurge 11y ago
I run into so many compiler bugs. Examples: g++, ghc, booc. I remember one time playing around with Unity3D, and for some reason decided to use the Boo language to write my code. I ended up having to patch booc to work around about a dozen different bugs. There's also the time I caused a kernel panic on CentOS 5 by running g++ on my code. It did so reliably, so I moved development to CentOS 6. Older gdbs on CentOS 4 will segfault if you run it on a binary compiled with ghc and ask for a backtrace. One time, I wrote a Perl module that unintentionally trashed the Perl interpreter's error tracking information. So if the module compiled, it worked fine. But if you had even a single variable mis-spelled or missing semicolon, all you'd get from perl is the error "Unknown error". Or even something as simple as writing a negative integer literal bugs out ghc: https://ghc.haskell.org/trac/ghc/ticket/9533 https://ghc.haskell.org/trac/ghc/ticket/9533 Compilers are absolutely riddled with bugs.
- mkj 11y ago
  Your examples sound more like bugs in the Linux kernel or gdb.
loup-vaillant 11y ago
(Edit: oops, I haven't read your second line…) [Indeed,] There's more to it than bugs. Undefined behaviour for instance is generally understood by the programmer as being runtime driven craziness. Divide by zero for instance will raise a clean error (generally resulting in a clean crash) on most platform. Popular C compilers such as GCC and LLVM however, have a different understanding, based on the wording of the standard. They are allowed to assume that undefined behaviour simply doesn't happen, and use that assumptions in optimizations such as dead code elimination or alias analysis. With this stuff, a program that would have exhibited undefined behaviour if compiled straightforwardly is allowed to go bananas at any time. This is compile time driven craziness, a rather different beast. A classic example of this is signed integer overflow. You perform some arithmetic that may overflow, then check for overflow after the fact. Most architectures perform two's complement modulo arithmetic, so it works without problem. Except that in C, this is undefined behaviour. So your compiler is allowed to assume it never happens. Which means your test that `x >= x+1` is going to be "true" all the time. Which means that your error handling branch is dead code. And that could allow nasty stuff such as buffer overflows. You could say it's the user's fault for relying on undefined behaviour (that is nevertheless well defined on x86 and ARM assembly). But you gotta admit that's not very intuitive. Yes, in some obscure platforms such an overflow could make your CPU jump in a random place. Yes, relying on this is not portable. But C is supposed to be close to the metal. Few C users would expect the compiler to optimize it all away even if it would work on their platform. On the other hand, things like strict aliasing are explicitly about enabling compiler optimizations.

randomsearch 11y ago

Compiler bugs are not rare, quite the opposite, and this is often because of premature optimisation. For example, GPGPU compilers are awful: http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2015/PLDI_Fuzzing.pdf http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2015/PLDI...

DannyBee 11y ago
It's more that compiler vendors who compete mainly on the basis of worthless benchmarks do awful things. This is one of the reasons gcc/llvm won: they don't care about that stuff. I mean, they care about performance, but not at all costs like these guys care. At some point, people wanted compilers that did less stupid things. So they moved to the vendors who did that. The reason it's so awful in the GPGPU space is because none of these vendors produce compilers yet. Instead, the vendors you have are those whose main goal in life is to generate better performance numbers than the other guy. Ask anyone about the old days of fortran compilers and early optimizing C compilers and what have you. What exists now is essentially "what happened after the market pushed back". Sadly, it didn't go as far as some people want (in either direction).
- loup-vaillant 11y ago
  > This is one of the reasons gcc/llvm won: they don't care about that stuff. I mean, they care about performance, but not at all costs like these guys care. Really? http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201... https://news.ycombinator.com/item?id=11219874 https://news.ycombinator.com/item?id=11219874 While GCC and LLVM do care about implementing the standard correctly, they show little mercy to the poor developer who failed to avoid one of the many sharp corners of undefined behaviour.
  - DannyBee 11y ago
    Yes. Really. There was a long thread about this just a few days ago (https://news.ycombinator.com/item?id=11219874 https://news.ycombinator.com/item?id=11219874) I already commented there, and since i didn't always have pleasant things to say, i'm not going to repeat them here.

MichaelBurge 11y ago

I run into so many compiler bugs. Examples: g++, ghc, booc. I remember one time playing around with Unity3D, and for some reason decided to use the Boo language to write my code. I ended up having to patch booc to work around about a dozen different bugs. There's also the time I caused a kernel panic on CentOS 5 by running g++ on my code. It did so reliably, so I moved development to CentOS 6. Older gdbs on CentOS 4 will segfault if you run it on a binary compiled with ghc and ask for a backtrace. One time, I wrote a Perl module that unintentionally trashed the Perl interpreter's error tracking information. So if the module compiled, it worked fine. But if you had even a single variable mis-spelled or missing semicolon, all you'd get from perl is the error "Unknown error". Or even something as simple as writing a negative integer literal bugs out ghc: https://ghc.haskell.org/trac/ghc/ticket/9533 https://ghc.haskell.org/trac/ghc/ticket/9533 Compilers are absolutely riddled with bugs.

mkj 11y ago
Your examples sound more like bugs in the Linux kernel or gdb.

loup-vaillant 11y ago

(Edit: oops, I haven't read your second line…) [Indeed,] There's more to it than bugs. Undefined behaviour for instance is generally understood by the programmer as being runtime driven craziness. Divide by zero for instance will raise a clean error (generally resulting in a clean crash) on most platform. Popular C compilers such as GCC and LLVM however, have a different understanding, based on the wording of the standard. They are allowed to assume that undefined behaviour simply doesn't happen, and use that assumptions in optimizations such as dead code elimination or alias analysis. With this stuff, a program that would have exhibited undefined behaviour if compiled straightforwardly is allowed to go bananas at any time. This is compile time driven craziness, a rather different beast. A classic example of this is signed integer overflow. You perform some arithmetic that may overflow, then check for overflow after the fact. Most architectures perform two's complement modulo arithmetic, so it works without problem. Except that in C, this is undefined behaviour. So your compiler is allowed to assume it never happens. Which means your test that `x >= x+1` is going to be "true" all the time. Which means that your error handling branch is dead code. And that could allow nasty stuff such as buffer overflows. You could say it's the user's fault for relying on undefined behaviour (that is nevertheless well defined on x86 and ARM assembly). But you gotta admit that's not very intuitive. Yes, in some obscure platforms such an overflow could make your CPU jump in a random place. Yes, relying on this is not portable. But C is supposed to be close to the metal. Few C users would expect the compiler to optimize it all away even if it would work on their platform. On the other hand, things like strict aliasing are explicitly about enabling compiler optimizations.