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
