5 ms·

A Compiler Bug (2023)

39 points by pbrowne011 2y ago

deleted 2y ago
[deleted]
userbinator 2y ago
I have, in various projects over the years, resorted to inline Asm when I couldn't coerce the compiler to do exactly what I wanted; including very rare compiler bugs.
bobmcnamara 2y ago
Haha! It's ARM compiler 4!
- deleted 2y ago
  [deleted]
- jeffreygoesto 2y ago
  We found bugs in that one as well. ARM even sent us their pre-release binaries some time. We had pretty templaze-heavy code and unit tests. When Visual Studio and gcc (and the standard) agreed on one outcome and RealView on another, we reported it. Record was three hours after receiving the compiler we reported a bug. One ARM person once said: "You know, we thought we build these CPUs, so we'd be the ones optimizing best for it. Boy did we learn how complicated C++ is. Next version will be based on clang..."
  - bobmcnamara 2y ago
    Somewhere there's this great CMSIS-DSP ticket: creator complains that CMSIS uses volatile loads/stores for GCC. Creator remove volatile, GCC reorders instructions to require larger number of in-flight registers, spills everything to the stack and tanks the FFT speed.
sligor 2y ago
Volatile were buggy in old compiler: https://llvm.org/pubs/2008-10-EMSOFT-Volatiles.html https://llvm.org/pubs/2008-10-EMSOFT-Volatiles.html [2008 paper] Even if compilers are better now, if possible it is better to wrap any IO memory access into ioread/iowrite inline (no cost) functions. This can then be implemented in a way known to be safe for the compiler used. And that can be changed easily in case the architecture or the compiler changes ( yeah abstraction ! ) As linux does for example: https://www.kernel.org/doc/html/v4.15/driver-api/device-io.html https://www.kernel.org/doc/html/v4.15/driver-api/device-io.h...
- deleted 2y ago
  [deleted]
kookamamie 2y ago
Searches for "volatile"...ahh, there it is.
vintagedave 2y ago
> the compiler vendor took care of it promptly in a paid upgrade to proprietary compiler 5.next Ouch (assuming that this required them to pay to get the bugfix.)
- rsaxvc 2y ago
  Long enough ago I don't remember the business details. The 4.x compiler line never being patched was a bit of eye opener into commercial toolchain support.
486sx33 2y ago
It’s never the compiler, it can’t be the compiler. The first rule of debugging is that it can’t be the compiler… Wow does it ever suck and waste a ton of time when it IS the compiler. I feel sorrow for whomever had to find this out in their workflow
- rsaxvc 2y ago
  I was still learning assembly, it took me a while to be sure it wasn't my bug.

39 points by pbrowne011 2y ago

deleted 2y ago

[deleted]

I have, in various projects over the years, resorted to inline Asm when I couldn't coerce the compiler to do exactly what I wanted; including very rare compiler bugs.

bobmcnamara 2y ago

Haha! It's ARM compiler 4!

deleted 2y ago
[deleted]
jeffreygoesto 2y ago
We found bugs in that one as well. ARM even sent us their pre-release binaries some time. We had pretty templaze-heavy code and unit tests. When Visual Studio and gcc (and the standard) agreed on one outcome and RealView on another, we reported it. Record was three hours after receiving the compiler we reported a bug. One ARM person once said: "You know, we thought we build these CPUs, so we'd be the ones optimizing best for it. Boy did we learn how complicated C++ is. Next version will be based on clang..."
- bobmcnamara 2y ago
  Somewhere there's this great CMSIS-DSP ticket: creator complains that CMSIS uses volatile loads/stores for GCC. Creator remove volatile, GCC reorders instructions to require larger number of in-flight registers, spills everything to the stack and tanks the FFT speed.

sligor 2y ago

Volatile were buggy in old compiler: https://llvm.org/pubs/2008-10-EMSOFT-Volatiles.html https://llvm.org/pubs/2008-10-EMSOFT-Volatiles.html [2008 paper] Even if compilers are better now, if possible it is better to wrap any IO memory access into ioread/iowrite inline (no cost) functions. This can then be implemented in a way known to be safe for the compiler used. And that can be changed easily in case the architecture or the compiler changes ( yeah abstraction ! ) As linux does for example: https://www.kernel.org/doc/html/v4.15/driver-api/device-io.html https://www.kernel.org/doc/html/v4.15/driver-api/device-io.h...

deleted 2y ago
[deleted]

kookamamie 2y ago

Searches for "volatile"...ahh, there it is.

vintagedave 2y ago

> the compiler vendor took care of it promptly in a paid upgrade to proprietary compiler 5.next Ouch (assuming that this required them to pay to get the bugfix.)

rsaxvc 2y ago
Long enough ago I don't remember the business details. The 4.x compiler line never being patched was a bit of eye opener into commercial toolchain support.

486sx33 2y ago

It’s never the compiler, it can’t be the compiler. The first rule of debugging is that it can’t be the compiler… Wow does it ever suck and waste a ton of time when it IS the compiler. I feel sorrow for whomever had to find this out in their workflow

rsaxvc 2y ago
I was still learning assembly, it took me a while to be sure it wasn't my bug.