Optimisations and undefined behaviour

[Andrew Haley]

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.

Andrew.