On Sun, 2017-03-05 at 11:24 -0600, Segher Boessenkool wrote: > On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote: > > > > Erk sorry. One of the static checkers spotted it, but I hadn't got > > > > around to fixing it because it seemed to not actually blow up, guess > > > > not. > > > > > > The PowerPC divw etc. instructions do not trap by themselves, but recent > > > GCC inserts trap instructions on code paths that are always undefined > > > behaviour (like, dividing by zero). > > > > Is it systematic or does it depend from, e.g., optimization levels? > > In this case it needs -fisolate-erroneous-paths-dereference which is > default at -O2 and higher. > > > Is there anything in the standards about this feature? > > The compiler can do whatever it likes with code that has undefined > behaviour. With this optimisation it a) can compile the conforming > code to something better; and b) undefined behaviour will trap instead > of doing something random (which often is exploitable).
I actually like that feature, except it did bite me once or twice in the past adding traps to intentional NULL dereferences ;-) Ah the joys of writing a firmware where you poke at stuff at fixed addresses in low memory :-) Cheers, Ben.
