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.
Jakub
