reordering of trapping operations and volatile

Paul Koning
Sat Jan 15 21:38:11 GMT 2022

> On Jan 15, 2022, at 4:28 PM, Martin Sebor <> wrote:
> On 1/14/22 07:58, Paul Koning via Gcc wrote:
>>> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc <> wrote:
>>>> ...
>>> 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. 

I was thinking that if a new feature is involved, rather than a new definition of behavior for existing code, it wouldn't be a constraint on existing implementations (in the sense of "what the compiler does for existing code written to the current rules").  In other words, suppose there was a concept of "trapping operations" that could be enabled by some new mechanism in the program text.  If you use that, then you're asking the compiler to do more work and your code may get slower or bigger.  But if you don't, the existing rules apply and nothing bad happens (other than that the compiler is somewhat larger and more complex due to the support for both cases).


More information about the Gcc mailing list