Optimisations and undefined behaviour

[David Brown]

On 09/11/15 13:42, Vincent Lefevre wrote:
> 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).
> 

Correct.

The ideal here is to get an /unspecified/ integer - without the risk of
a trap or undefined behaviour.  Implementation-defined behaviour that is
known to be safe on gcc is a step forward - I am aware that the ideal
here is not possible in standard and portable C.

In this particular example, implementation-dependent behaviour is fine.
 But in some circumstances, unspecified behaviour /may/ be even better
as it gives the compiler complete freedom for optimisation.  Here the
compiler is required to generate a specific result, as calculated using
the implementation-specified rules.