On Sun, Mar 05, 2017 at 11:24:56AM -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.
Great, another optimization-dependent behaviour. :-(
But this is not the most serious issue: on PPC, when you #include
<limits>, the numeric_limits<any_integer_type>::traps is false on PPC,
and on no other architecture that I know of (in practice this trap
reflects the hardware behaviour on division by zero).
By generating a trap in this case, I believe that the compiler violates
a contract given by <limits>, and the standard.
I'd certainly prefer a compile time warning, easily convertible to an
error.
>
> > 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).
It may be undefined, but I believe that the numeric_limits<>::traps
value clearly prohibits generating a trap in this case.
Gabriel
