Am Montag, dem 01.07.2024 um 15:19 +0200 schrieb Matthias Kretz:
> On Sunday, 30 June 2024 08:33:35 GMT+2 Martin Uecker wrote:
> > Am Sonntag, dem 30.06.2024 um 05:03 +0200 schrieb Matthias Kretz:
> > > On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote:
> > > > Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via
> Gcc:
> > > > >
,
..
> >
> > > > But I am not sure how this is relevant here as this affects only
> > > > observable behavior and the only case where GCC does not seem to
> > > > already conform to this is volatile.
> > >
> > > Now you lost me.
> >
> > Consider the following example:
> >
> > int f(int x)
> > {
> > int r = 0;
> > if (x < 10)
> > r = 1;
> > if (x < 10)
> > __builtin_unreachable();
> > return r;
> > }
> >
> > But removing the store to 'r' here as GCC does:
> >
> > https://godbolt.org/z/h7qqrGsbz
> >
> > can simply be justified by the "as if" principle as
> > any other optimization, it does not need to rely on a weird
> > intepretation that the UB from __builin_unreachable() travels
> > back in time.
>
> I don't know of anybody saying that "time-travel optimization" refers to
> anything different than what you're showing here.
The C++ standard allows also removing or changing previous
observable behavior.
"However, if any such execution contains an undefined operation,
this International Standard places no requirement on the implementation
executing that program with that input (not even with regard to
operations preceding the first undefined operation)."
This was discussed extensively in the past, e.g. when discussing
the specification for memset_explicit.
> The part that people find
> scary is when this "as if" happens at a distance, like in
> https://godbolt.org/z/jP4x1c3E6
True, although without "true time travel" (i.e. excluding
time-travel affecting previous observable behavior), this is
limited in the damage it can do (e.g. can not undo changes
committed to a log or control inputs to an external machine)
and has a much simpler interpretation that does not need to
refer to metaphysical concepts: Instead of the UB affecting
previous behavior by travelling back in time, it just has
arbitrary behavior that might undo the store.
>
> > > [...]
> >
> > I think it is a good idea. The compiler can optionally treat UB as
> > a translation time error. We discussed similar ideas in the past
> > in WG14. But this will only work for very specific instances of UB
> > under certain conditions.
>
> Yes. But it's an exact match of the "time-travel" cases. I.e. whenever const-
> prop determines "unreachable" the code could be ill-formed.
I am not sure it is so simple. What about if all this is in
dead code? I assume one needs a rule similar to "for a functions,
when it is not possible to invoke the function without reaching
an operation which has UB, then the program ill-formed." or
"if a function call expression always invokes UB when executed,
then...". I guess the later is would apply to the precondition
viplations you mentioned WG21 is considering.
>
>
> > > > Also IMHO this should be split up from
> > > > UBsan which has specific semantics and upstream dependencies
> > > > which are are not always ideal. (But UBSan could share the
> > > > same infrastructure)
> > >
> > > I'm not sure what you're thinking of here. UBsan detects UB at runtime
> > > whereas my '-fharden=1' proposal is about flagging UB as ill-formed on
> > > compile-time. So UBsan is a more verbose '-fharden=2' then?
> >
> > Yes, I was talking about the -fharden=2 case. In principle UBSan
> > with traps instead of diagnostics would do this. In practice,
> > I think we need something which is not tied to UBSan.
>
> Yes, basically a deployable variant of UBsan?
>
Yes, there is something such as -fcf-protection
or -fvtable-verify
Martin
>
> On Sunday, 30 June 2024 08:56:41 GMT+2 Martin Uecker wrote:
> > 0) nothing
> > 1) expands to __builtin_unreachable()
> > 2) expands to __builtin_trap()
> > 3) expands to a __builtin_warning (as suggested before
> > by Martin Sebor) that causes the backend to emit an error
> > in a very late pass when the __builtin_warning has not
> > been removed during optimization.
>
> This __builtin_warning seems to be equivalent to my __error() function, using
> a [[gnu::warning]] attribute instead of [[gnu::error]]. Which is certainly
> another viable build/-fharden/whateverwecallit mode.
>
