Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via Gcc:
... > I.e. once UB becomes IFNDR, the dreaded time-travel optimizations can't > happen > anymore. Instead precondition checks bubble up because otherwise the program > is ill-formed. It is not clear to mean what you mean by this? Note that in C time-travel optimizations are already not allowed. 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. Of course, C++ may be different but I suspect that some of the discussion is confusing compiler bugs with time-travel: https://developercommunity.visualstudio.com/t/Invalid-optimization-in-CC/10337428?q=muecker > > Again, I don't believe this would be conforming to the C++ standard. But I > believe it's a very interesting mode to add as a compiler flag. > > -fharden=0 (default) > -fharden=1 (make UB ill-formed or unreachable) > -fharden=2 (make UB ill-formed or trap) > > If there's interest I'd be willing to look into a patch to libstdc++, > building > upon the above sketch as a starting point. Ultimately, if this becomes a > viable build mode, I'd like to have a replacement for the [[gnu::error("")]] > hack with a dedicated builtin. -fharden should never turn this into unreachable. But I agree that we should have options for different choices. IMHO the FEs should insert the conditional traps when requested to and the middle end could then treat it as UB and more freely decide what to do. 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) Martin
