Optimisations and undefined behaviour

[Vincent Lefevre]

On 2015-11-09 03:40:12 -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2015 at 09:28:49AM +0100, Vincent Lefevre wrote:
> > On 2015-11-08 18:49:46 -0600, Segher Boessenkool wrote:
> > > On Mon, Nov 09, 2015 at 01:27:34AM +0100, Vincent Lefevre wrote:
> > > > > Why not simply:
> > > > >   unsigned y = x;
> > > > >   return y*y*y;
> > > > > ? This is an example where defined behavior is so easy to get...
> > > > 
> > > > But what if the result of y*y*y (an unsigned int) does not fit in
> > > > an int?
> > > 
> > > That is implementation-defined. not undefined (6.3.1.3); GCC documents
> > > it like this:
> > > 
> > >      For conversion to a type of width N, the value is reduced modulo
> > >      2^N to be within range of the type; no signal is raised.
> > 
> > That's what GCC does, but what if the user uses another compiler
> > or GCC decides to change this behavior in the future?
> 
> Then it is still not undefined behaviour.  It can give different results
> of course.

... including a signal, which is not acceptable for the OP, if I
understand correctly ("we don't care about the result in such cases"
doesn't imply that the program may terminate immediately).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)