(no title)
Vipsy
|
4 months 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.
pjmlp|4 months ago
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
peterfirefly|4 months ago
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|4 months ago
SuperQue|4 months ago
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)
unknown|4 months ago
[deleted]
kmarc|4 months ago
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|4 months ago