Re: reordering of trapping operations and volatile

[Paul Koning <paulkoning@comcast.net>]

> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc <gcc@gcc.gnu.org> wrote:
> 
> Hello,
> 
> On Thu, 13 Jan 2022, Martin Uecker wrote:
> 
>>>>> Handling all volatile accesses in the very same way would be 
>>>>> possible but quite some work I don't see much value in.
>>>> 
>>>> I see some value. 
>>>> 
>>>> But an alternative could be to remove volatile
>>>> from the observable behavior in the standard
>>>> or make it implementation-defined whether it
>>>> is observable or not.
>>> 
>>> But you are actually arguing for making UB be observable
>> 
>> No, I am arguing for UB not to have the power
>> to go back in time and change previous defined
>> observable behavior.
> 
> But right now that's equivalent to making it observable,
> because we don't have any other terms than observable or
> undefined.  As aluded to later you would have to
> introduce a new concept, something pseudo-observable,
> which you then started doing.  So, see below.

I find it really hard to view this notion of doing work for UB with any favor.  The way I see it is that a program having UB is synonymous with "defective program" and for the compiler to do extra work for these doesn't make much sense to me.

If the issue is specifically the handling of overflow traps, perhaps a better answer would be to argue for language changes that manage such events explicitly rather than having them be undefined behavior.  Another (similar) option might be to choose a language in which this is done.  (Is Ada such a language?  I don't remember.)

	paul