Thread (15 messages) flat view 15 messages, 8 authors, 2017-03-08

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

From: Gabriel Paubert <hidden>
Date: 2017-03-06 12:04:06

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:
quoted
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help