I have lost all morning due to a bug in xf86-video-intel. Building it with -O0 did the trick. Still it is astonishing how much software can easily break.
Usually when aggressive optimizations break something, it's a bug in the program compiled. This happens because these optimizations rely on undefined behaviour and strict code.
I have been using -O3 at a system level for years now, and this has been one of the few bugs I have encountered.
I want to fix it but it would probably require me sometime to understand the huge codebase and flow.
@danyspin97 There is also the possibility that the optimizations don't play well with hardware access. That would be real fun to diagnose without the use of hardware-level debugging.
That's a possibility too. I am curious, how would be possible to debug in this scenario? I don't have much experience with hardware level and access.
@danyspin97 You would have to use a Logic Analyser.
This device has probes which connect to the processors buses. You can collect bus timings and there's usually a machine code disassembler to determine what's happening.
I've used them on 8/16 bit microprocessor-based systems but not on the scale of a modern PC. I wouldn't want to guess at the cost of ownership for a device suitable for debugging your scenario.
@neildarlow thanks for the detailed explanation. Yea, it seems a real pain to debug on a modern PC. I'll look up Logic Analyser out of curiosity.
@danyspin97 I would imagine that any modern Logic Analyser would make use of a JTAG interface built-into the CPU.
Connecting hundreds of wires onto a motherboard wouldn't be practical.
@danyspin97 Was that a bug in the driver or compiler?
If reducing the amount of optimisation fixes it then I'd suspect the compiler.