Optimisations and undefined behaviour

[Richard Earnshaw]

On 09/11/15 15:22, Andrew Haley wrote:
> On 11/09/2015 03:05 PM, Richard Earnshaw wrote:
>> On 09/11/15 15:00, Andrew Haley wrote:
>>> On 11/09/2015 02:56 PM, Richard Earnshaw wrote:
>>>> On 09/11/15 14:29, Andrew Haley wrote:
>>>
>>>>> Here it is again:
>>>>>
>>>>> int foo(int x) {
>>>>> 	if (x > 1290) {
>>>>> 		printf("X is wrong here %d, but we don't care\n", x);
>>>>> 	}
>>>>> 	return x*x*x;
>>>>>
>>>>> Here, the printf writes to a stream then the UB happens.  
>>>>
>>>> Not if setvbuf has been used to make the stream unbuffered.
>>>
>>> It hasn't.  And I know it hasn't because it's my example.
>>
>> A compiler would still need to do whole-program analysis to prove that;
>> it can't work on the assumption that it hasn't been done.
> 
> I'm not sure about that: see below.
> 
>>> And besides, the UB might cause the computer to crash before the
>>> data has been written to stdout by the kernel; the same reasoning
>>> applies.
>>
>> UB that causes the machine to crash is, I think, outside of what we need
>> to think about.  Any machine that's falls over in that case is not
>> interesting.
> 
> Well, in that case you'll have to define what you think we are
> supposed to be thinking about.  I don't think you are talking about
> the C language as it is specified, you're talking about some
> implementation on some machine, and of course I can't argue with you
> about what that machine does because I don't know anything about it.
> Such a discussion is IMO pointless because everyone can just Make
> Stuff Up.
> 
> I do know that once UB has happened in a program, the whole program is
> undefined and the language specification imposes no requirements on it
> at all.  I don't see any language in the specification which requires
> prior operations with side effects to have completed.
> 
> But should we treat all potential UB as having a side effect,
> (essentially treating it like a volatile) so that it cannot be moved
> past a sequence point?  I wouldn't have thought so, but perhaps we
> could.
> 

We've certainly done that for specific cases in the past.  For example,
we don't hoist some division operations in case they might have a
divisor of zero.

R.

> Andrew.
>