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. > 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.
That's fair. How would you suggest we can improve -fwrapv-pointer documentation? What does -fwrapv-pointer guarantee? I'm not sure the kernel used the pointer aspect of -fno-strict-overflow conciously or because any concrete "mishandling" of pointers? Do you remember any specific PR? Richard.
