4 ms·

“ There's a common saying and rule of thumb in programming (possibly originating in the C world) that it's never a compiler bug, it's going to be a bug in your

by helmsb 4y ago

“ There's a common saying and rule of thumb in programming (possibly originating in the C world) that it's never a compiler bug, it's going to be a bug in your code even if it looks crazy or impossible.” I say, it’s “rarely a compiler bug.” When teaching new developers I remind them that you should assume the bug is in the code you just wrote before jumping to the bug being a compiler, framework or OS issue. It’s just a matter of probabilities.

plumefar 4y ago
In my +- 25 years of experience, I've encountered exactly 1 compiler bug. That cost me a full week of debug. Unfortunately, it happened during my very first year as a developer, and that triggered sub-optimal debugging practices (ie: is that the compiler fault again?) At the end of the day, you want to optimise for debug time. There's the probability that it's a compiler/developer bug (respectively very low/very high) and the time it takes to rule it out. It's of course best NOT to start by investigating the compiler bug.
- bondant 4y ago
  I think it's really dependent of the domain you are working in. Some stuff is better tested than others. In my 5 years careers I found bugs (found and confirmed by compiler authors) in gfortran, xlf and pgfortran. So yes bugs in compilers are rare but sometimes you just keep running into them.
  - dtech 4y ago
    those are quite niche languages though, most people use compilers which are much more widely used.
    - capitalsigma 4y ago
      Clang support for AVX-512 intrinsics is pretty broken
- CameronNemo 4y ago
  Yeah I was debugging an issue that was occurring in a Kubernetes environment last night... kept wanting to blame the out of date Istio version. I just could not trust it and that lack of trust stopped me from seeing the whitespace error that was in front of me the whole time...
- Agingcoder 4y ago
  I find several every year. Most people simply don't see compiler bugs because they don't test (and most of the time don't need to) their compilers extensively enough (by testing I mean they must build, run the generated binaries, and compare the output ).
  - karamanolev 4y ago
    That sounds very weird, unless you are working 1) With with an esoteric environment that has relatively few users. 2) Have specific objectives that require a lot of edge case testing or ridiculously thorough fuzzing of the binary. 3) Go out looking for them by crafting nifty things that aren't much used. Otherwise it would imply large companies (Google-scale) experience thousands of compiler bugs per year...
    - addaon 4y ago
      > Otherwise it would imply large companies (Google-scale) experience thousands of compiler bugs per year... This seems likely to be true, from my experience. Fortunately, most compiler bugs I run into (mostly with gcc and llvm) are not code generation bugs (which can eat months of debugging), but just segfaults / rejecting correct code / other broken stuff.
      - josephg 4y ago
        I also suspect most programmers spend most of their time staying more or less on the “straight and narrow”. There’s lots of obscure features in most languages (especially in old languages like C++) that not many programmers use. These features are much more likely to have buggy edge cases in the compiler. And only a small select group of programmers will run into those bugs over and over again. Eg complex template metaprogramming - which had known broken corner cases in all C++ compilers up until a decade or so ago.
    - astrange 4y ago
      If you don't hit compiler bugs, it's mostly because you're not updating your compiler. Large companies with compiler teams want to use them, so they do update their compiler, so they will find bugs in it. Btw, what do you think this prints with clang? (Whether the answer is a compiler bug is debatable…) printf("%#x\n", 1 << 32);
CodesInChaos 4y ago
In C it's usually undefined behaviour that causes the compiler to produce code that doesn't behave as expected. So not actually a compiler bug, but indistinguishable from one until you identify the UB.
- cormacrelf 4y ago
  I’ve found two compiler bugs, both in rustc. One was a hang, so obvious. But the other, I and the people chiming in pretty quickly figured out it was a codegen problem, as it turned out due to enabling noalias before it was ready. Just cut swaths of code until you get it down to no unsafe. It was a pretty good experience.
  - touisteur 4y ago
    Delta debugging and C-reduce are your friends there. I dearly miss creduce in my language of choice... Not that compiler bugs are that frequent but when generating so much weird code I tend to trigger them bugs more frequently.
ilyt 4y ago
They say that because people that don't have enough knowledge yet to even check whether it's compiler/tooling bug will blame compiler/tooling
jdwithit 4y ago
Doing zero troubleshooting and immediately jumping to the conclusion that it's someone else's fault is frustratingly common. If you want to make a network engineer reflexively reach for a bottle of liquor, DM them on Slack "hey is the network down my app/service/database/whatever is unreachable". Networks can and do go down of course. But in my experience, the vast majority of these issues are actually the result of something extremely mundane like a typo in a hostname. I've resolved an incredible number of issues over the years by simply reading the error message someone sent to me and asking them to check the exact thing that the message says is wrong.
theLiminator 4y ago
I've found that as I get increasingly experienced/skilled, that ratio of the problem being in my code vs compiler, framework or OS issue decreases. Not that most problems still aren't in my code, but I've increasingly run into framework/library level issues and very rarely compiler issues. Can't say I've triggered any kernel issues yet.
nubinetwork 4y ago
https://bugs.gentoo.org/724314 https://bugs.gentoo.org/724314 Compiler bug or CPU issue, take your pick :)
asah 4y ago
Rarely yes. Never, haha not my experience. I've seen bugs in EVERYTHING, and let's not forget hardware bugs like pentium math.

by helmsb 4y ago

plumefar 4y ago

In my +- 25 years of experience, I've encountered exactly 1 compiler bug. That cost me a full week of debug. Unfortunately, it happened during my very first year as a developer, and that triggered sub-optimal debugging practices (ie: is that the compiler fault again?) At the end of the day, you want to optimise for debug time. There's the probability that it's a compiler/developer bug (respectively very low/very high) and the time it takes to rule it out. It's of course best NOT to start by investigating the compiler bug.

bondant 4y ago
I think it's really dependent of the domain you are working in. Some stuff is better tested than others. In my 5 years careers I found bugs (found and confirmed by compiler authors) in gfortran, xlf and pgfortran. So yes bugs in compilers are rare but sometimes you just keep running into them.
- dtech 4y ago
  those are quite niche languages though, most people use compilers which are much more widely used.
  - capitalsigma 4y ago
    Clang support for AVX-512 intrinsics is pretty broken
CameronNemo 4y ago
Yeah I was debugging an issue that was occurring in a Kubernetes environment last night... kept wanting to blame the out of date Istio version. I just could not trust it and that lack of trust stopped me from seeing the whitespace error that was in front of me the whole time...
Agingcoder 4y ago
I find several every year. Most people simply don't see compiler bugs because they don't test (and most of the time don't need to) their compilers extensively enough (by testing I mean they must build, run the generated binaries, and compare the output ).
- karamanolev 4y ago
  That sounds very weird, unless you are working 1) With with an esoteric environment that has relatively few users. 2) Have specific objectives that require a lot of edge case testing or ridiculously thorough fuzzing of the binary. 3) Go out looking for them by crafting nifty things that aren't much used. Otherwise it would imply large companies (Google-scale) experience thousands of compiler bugs per year...
  - addaon 4y ago
    > Otherwise it would imply large companies (Google-scale) experience thousands of compiler bugs per year... This seems likely to be true, from my experience. Fortunately, most compiler bugs I run into (mostly with gcc and llvm) are not code generation bugs (which can eat months of debugging), but just segfaults / rejecting correct code / other broken stuff.
    - josephg 4y ago
      I also suspect most programmers spend most of their time staying more or less on the “straight and narrow”. There’s lots of obscure features in most languages (especially in old languages like C++) that not many programmers use. These features are much more likely to have buggy edge cases in the compiler. And only a small select group of programmers will run into those bugs over and over again. Eg complex template metaprogramming - which had known broken corner cases in all C++ compilers up until a decade or so ago.
  - astrange 4y ago
    If you don't hit compiler bugs, it's mostly because you're not updating your compiler. Large companies with compiler teams want to use them, so they do update their compiler, so they will find bugs in it. Btw, what do you think this prints with clang? (Whether the answer is a compiler bug is debatable…) printf("%#x\n", 1 << 32);

CodesInChaos 4y ago

In C it's usually undefined behaviour that causes the compiler to produce code that doesn't behave as expected. So not actually a compiler bug, but indistinguishable from one until you identify the UB.

cormacrelf 4y ago
I’ve found two compiler bugs, both in rustc. One was a hang, so obvious. But the other, I and the people chiming in pretty quickly figured out it was a codegen problem, as it turned out due to enabling noalias before it was ready. Just cut swaths of code until you get it down to no unsafe. It was a pretty good experience.
- touisteur 4y ago
  Delta debugging and C-reduce are your friends there. I dearly miss creduce in my language of choice... Not that compiler bugs are that frequent but when generating so much weird code I tend to trigger them bugs more frequently.

ilyt 4y ago

They say that because people that don't have enough knowledge yet to even check whether it's compiler/tooling bug will blame compiler/tooling

jdwithit 4y ago

Doing zero troubleshooting and immediately jumping to the conclusion that it's someone else's fault is frustratingly common. If you want to make a network engineer reflexively reach for a bottle of liquor, DM them on Slack "hey is the network down my app/service/database/whatever is unreachable". Networks can and do go down of course. But in my experience, the vast majority of these issues are actually the result of something extremely mundane like a typo in a hostname. I've resolved an incredible number of issues over the years by simply reading the error message someone sent to me and asking them to check the exact thing that the message says is wrong.

theLiminator 4y ago

I've found that as I get increasingly experienced/skilled, that ratio of the problem being in my code vs compiler, framework or OS issue decreases. Not that most problems still aren't in my code, but I've increasingly run into framework/library level issues and very rarely compiler issues. Can't say I've triggered any kernel issues yet.

nubinetwork 4y ago

https://bugs.gentoo.org/724314 https://bugs.gentoo.org/724314 Compiler bug or CPU issue, take your pick :)

asah 4y ago

Rarely yes. Never, haha not my experience. I've seen bugs in EVERYTHING, and let's not forget hardware bugs like pentium math.