Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

[Gabriel Paubert <paubert@iram.es>]

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