On Mon, 21 Sep 2026, Jakub Jelinek wrote: > On Mon, Sep 21, 2026 at 03:10:32PM +0200, Richard Biener wrote: > > Under -fwrapv-pointer, pointer overflow/wrap is well-defined. > > This patch ensures that IVOPTS does not make non-overflow assumptions > > for pointer types when flag_wrapv_pointer is active. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > > > Documentation is a bit vague about the effects of -fwrapv-pointer, > > but IIRC the intention(?) was pointer arithmetic behaves like > > it was done on an unsigned integer type, thus C pointer arithmetic > > within-object rules do not apply, neither does wrapping around zero. > > That would also mean -fno-delete-null-pointer-checks that guard > > comparisons might need to go? The middle-end treats &<...> > > as pointer arithmetic, so that would even apply to &a->p != 0 then, > > irrespective of the offset of p? PTA most definitely also gets > > this wrong, the question is whether we should really fix it up > > in the way of the patch or require the IL to actually use an > > unsigned integer type in the first place? > > > > Of course test coverage is quite bad here. > > I think the point of -fwrapv-pointer was to keep compiling Linux kernel with > its strange view of what C is, so I'd hope we don't need for > -fno-strict-overflow to disable PTA/IPA-PTA etc. because if we document > that -fwrapv-pointer implies pointer arithmetic rules don't exist at all, > PTA etc. can't do anything either.
Correct. But if people want to have pointers behave like twos-complement values what can we do? We could separate wrapping from "provenance", and thus add -fno-pointer-provenance, but I'm also a bit sick of "kernel C" ... > Sure, any pointer overflow necessarily means UB because then it can't point > into the same array. I think kernel only needs it for pointers where the > compiler can't know what the pointer points to. > If we really need some other option which would say all of the pointer > arithmetics rules can be ignored, then yes, I think we should be > representing it as pointer_sized_int arithmetics on casts and then casts > back. > > I'd close the PR as NOTABUG or WONTFIX. ... so I went this way, or rather classifed as documentation. I will propose adding a caveat to -fwrapv-pointer docs. Ricahrd. > Jakub > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
