On Tue, Sep 09, 2025 at 06:14:40PM +0300, Ville Voutilainen wrote:
> On Tue, 9 Sept 2025 at 18:11, Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Tue, Sep 09, 2025 at 06:08:12PM +0300, Ville Voutilainen wrote:
> > > The fail() can fall through when the contracts are evaluated in the
> > > "observe" evaluation mode.
> > > In that case it's not an actual "fail", it will call the contract
> > > violation handler and return from that.
> > >
> > > And then the concern is that that call may be completely elided
> > > because what follows is
> > > UB in the form of the pointer dereference.
> >
> > IMHO a correct compiler can't do that.
> > Because the contract violation handler could have validly exit (0)
> > or for (;;) ; etc. in it, so the UB wouldn't encountered in the program and
> > so it would be valid.
>
> The violation handler may be defined in the same translation unit, and
> its definition may be completely visible
> to the middle-end.
Sure, but so what? If it can't result in the UB not happening, doesn't
perform I/O (that would be also not something completely visible and
something the compiler shouldn't move UB across), doesn't perform thread
synchronization (such that other thread could without data races observe
memory stores it did and say exit), why is it wrong to move the UB earlier?
I don't see how a correct program could observe the difference.
Jakub
