On Mon, Mar 06, 2017 at 01:03:19PM +0100, Gabriel Paubert wrote: > > > > 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. :-(
It makes the "behaviour" for undefined behaviour *less* surprising. It does not change anything else: malformed programs stay malformed, correct programs do exactly what they did before, too. > 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. [ snip ] I have no idea why you are bringing C++ into this. Please open a PR if you think there is a bug in the C++ library. I'll note that this cannot violate the standard, see the "terms and definitions": [defns.undefined] undefined behavior behavior for which this International Standard imposes no requirements Segher
