Hello, On Tue, 9 Sep 2025, Jakub Jelinek wrote:
> > So, again, a precise spec of the supposed semantics of the builtin are > > required. Up to now it seems fairly fuzzy and all cases I've seen in this > > thread are trying to work around clear compiler or user bugs. > > > > So, what is or isn't guaranteed by the builtin? > > I think some pedantic readings of the standards suggest that if a program > invokes UB, it is invalid as whole and can do anything even before the point > of the UB. Which I think is true, It is true for some languages and some versions of them. I think e.g. recent C-family variants changed (or are going to change) this. For instance vis. the missing-return-in-nonvoid UB, the following argument once was correct: as UB can be anything-goes it could just as well be whatever is on paths not reaching the UB, hence replacement with builtin_unreachable was okay (and the folloup transformations that completely replace paths leading to that are then fine). But more recent variants of the respective standards clarify that towards anything-goes-within-reason. Replacement with builtin_unreachable isn't okay anymore, it has to be builtin_trap (or something akin to that). Paths leading to such code aren't unreachable in those language variants (or rather, aren't mergable with paths that were not leading to it). > but the compiler can't assume code > invokes UB if it calls something it doesn't know anything about (because > it could loop forever or exit or throw or setjmp out of the UB invoking > function etc. and so never actually invoke the UB) before the UB is > encountered. Exactly. Even with old language variants in which UB was sun-might-explode it was still necessary to prove that that UB _must_ happen. The nature of these cases is such that compiler bugs about that went unnoticed for a long time, and surprised people. And I have the feeling that the proposal at hand is more a result of such bugs and surprises, rather than a real need. I'm ready to be convinced otherwise, but for that we'd need a more precise definition of what are and what aren't the guarantees of the proposed extension. > So any movement of UB across such points is a compiler bug, while moving it > across some statements which certainly won't result in the later UB not > being invoked should be fine. Yes. But in order to inhibit moving of UB there need to be reasons: certain effects of the abstract machine need to be made observable in a certain order, and that observability and ordering needs to be influenced by the proposed extension. I'm asking about what the affected effects (ahem) are, and what the order will be. And in particular I'm asking what the _additional_ effects and ordering constraints will be compared to what already exists, because all these additional aspects need to be part of call statements then. Ciao, Michael.
