5 ms·

One thing that often gets missed is how hard it is to even suspect the compiler as the root cause. Most engineers waste hours chasing bugs in their own code bec

by Vipsy 11mo ago

One thing that often gets missed is how hard it is to even suspect the compiler as the root cause. Most engineers waste hours chasing bugs in their own code because we’re trained to trust our tools. This mindset alone can make these rare compiler bugs much trickier to find.

kmarc 11mo ago
There are certain professions where the compilation process is (ab)used to optimize to a point where these bugs seemingly surface more often. In the HFT sphere i haven't talked to a company that hasn't reported (bragged about finding) a super weird gcc/clang bug. Well, also, at my last job we used a snapshot version of the compiler, bc... Any nanoseconds matters.
- hshdhdhehd 11mo ago
  In HFT might you keep the bug fix secret so other HFTs cant benefit from it.
  - kmarc 11mo ago
    I saw both. One of the top firms wanted that, another I worked at we did report (of course with a scratched minimal reproducible example) The thing is, it's quite unlikely that your competitor hits the exact same bug. The cost of us having to keep upstream patched, tested isn't justified. Also in HFT world there are some very similar patterns across competing companies, yet, we just saw TernFS coming out from XTX, with not much fear of competitors benefiting from it more than they do.
SuperQue 11mo ago
Yup, I had an issue filed against an open source project I work on. Was a crazy weird crash. The reporter actually spent the effort to track it down, turns out it _was_ a Go compiler bug. (https://github.com/golang/go/issues/20427 https://github.com/golang/go/issues/20427)
pjmlp 11mo ago
In the early PC days we suspected them a lot given how manually writting Assembly was still much better, in many cases. I found out a bug on Turbo Pascal 6, where if you declare a variable with the same name as the function name, then the result was random garbage. For those that don't know Pascal, the function name has to be assigned for the result value, so if a local variable with the same name is possible, then you cannot set the return value. Something like this https://godbolt.org/z/s6srhTW66 https://godbolt.org/z/s6srhTW66 (* In Turbo Pascal 6 this would compile *) function Square(num: Integer): Integer; var Square: Integer; begin Square := num * num; (* Here the local variable gets used instead *) end;
- peterfirefly 11mo ago
  succ(seg(x)) and pred(seg(x)) turned out to be equivalent of just seg(x) in TP6. Earlier versions of Turbo Pascal (and Poly Pascal) generated poor code for "... + 1" but better code with succ(...) and doing memory access via memw[s:o] was common for speed for certain kinds of code. Allocating whatever size you needed + 16 guaranteed you had allocated enough to have paragraph aligned allocation (16 instead of 15 so you could just use the segment + 1). I think it took a day or two to find this bug in some text-mode windowing code I'd written.
Tor3 11mo ago
In the past it was more common to suspect the compiler, as others mention here. On a minicomputer I worked with in the late eighties, early nineties, I occasionally found errors in the compiler output. This was a Pascal compiler and because of that it didn't take too long to figure out that the code was actually correct and something else must be going on. Then firing up the debugger/tracer and scrutinizing and analyzing what happens in the disassembly.. when the problem was found, send a fax (yes!) to the head designer of the compiler, get a fixed test compiler back on a set of floppies.. went through this several times. I still have a printout somewhere with my pen marks pointing out a bug in the generated code.
deleted 11mo ago
[deleted]

by Vipsy 11mo ago

kmarc 11mo ago

There are certain professions where the compilation process is (ab)used to optimize to a point where these bugs seemingly surface more often. In the HFT sphere i haven't talked to a company that hasn't reported (bragged about finding) a super weird gcc/clang bug. Well, also, at my last job we used a snapshot version of the compiler, bc... Any nanoseconds matters.

hshdhdhehd 11mo ago
In HFT might you keep the bug fix secret so other HFTs cant benefit from it.
- kmarc 11mo ago
  I saw both. One of the top firms wanted that, another I worked at we did report (of course with a scratched minimal reproducible example) The thing is, it's quite unlikely that your competitor hits the exact same bug. The cost of us having to keep upstream patched, tested isn't justified. Also in HFT world there are some very similar patterns across competing companies, yet, we just saw TernFS coming out from XTX, with not much fear of competitors benefiting from it more than they do.

SuperQue 11mo ago

Yup, I had an issue filed against an open source project I work on. Was a crazy weird crash. The reporter actually spent the effort to track it down, turns out it _was_ a Go compiler bug. (https://github.com/golang/go/issues/20427 https://github.com/golang/go/issues/20427)

pjmlp 11mo ago

In the early PC days we suspected them a lot given how manually writting Assembly was still much better, in many cases. I found out a bug on Turbo Pascal 6, where if you declare a variable with the same name as the function name, then the result was random garbage. For those that don't know Pascal, the function name has to be assigned for the result value, so if a local variable with the same name is possible, then you cannot set the return value. Something like this https://godbolt.org/z/s6srhTW66 https://godbolt.org/z/s6srhTW66 (* In Turbo Pascal 6 this would compile *) function Square(num: Integer): Integer; var Square: Integer; begin Square := num * num; (* Here the local variable gets used instead *) end;

peterfirefly 11mo ago
succ(seg(x)) and pred(seg(x)) turned out to be equivalent of just seg(x) in TP6. Earlier versions of Turbo Pascal (and Poly Pascal) generated poor code for "... + 1" but better code with succ(...) and doing memory access via memw[s:o] was common for speed for certain kinds of code. Allocating whatever size you needed + 16 guaranteed you had allocated enough to have paragraph aligned allocation (16 instead of 15 so you could just use the segment + 1). I think it took a day or two to find this bug in some text-mode windowing code I'd written.

Tor3 11mo ago

In the past it was more common to suspect the compiler, as others mention here. On a minicomputer I worked with in the late eighties, early nineties, I occasionally found errors in the compiler output. This was a Pascal compiler and because of that it didn't take too long to figure out that the code was actually correct and something else must be going on. Then firing up the debugger/tracer and scrutinizing and analyzing what happens in the disassembly.. when the problem was found, send a fax (yes!) to the head designer of the compiler, get a fixed test compiler back on a set of floppies.. went through this several times. I still have a printout somewhere with my pen marks pointing out a bug in the generated code.

deleted 11mo ago

[deleted]