Re: reordering of trapping operations and volatile

[Martin Sebor <msebor@gmail.com>]

On 1/14/22 07:58, Paul Koning via Gcc wrote:
> 
> 
>> 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.

This is also the official position of the C committee on record,
but it's one that's now being challenged.

> 
> 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.)

A change to the language standard is only feasible if it doesn't
overly constrain existing implementations.  The impetus for Martin's
question here is to try to understand the impact on GCC.  Of course,
GCC is just one of many C implementations, and WG14 has only a very
limited visibility into existing compilers.  As a result, even if
GCC were not to be impacted by a change here, imposing requirements
that might have an adverse effect on other implementations isn't
likely to gain enough support.

Martin