[Bug middle-end/95903] gcc 10: wrong code with -fwrapv

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe all arrays larger than half of the address space are outside of the
standard already, one can't perform e.g. address arithmetics on those because
it overflows the ptrdiff_t in which it is evaluated.
It has been discussed in other PRs.
I don't know about aarch64 ilp32, but for several arches with 64-bit hw
pointers either the hw has some addressing mode that ignores the upper bits
(e.g. zero or sign extends addresses during access), or often the AS is even
limited to just half of the size, so that both sign and zero extension behave
the same.
If you believe there is a problem for aarch64, please file a separate PR and
the people familiar with that target needs to discuss it, certainly it is
unrelated to this, because at GIMPLE the sources just contain pointers and
pointers are 32-bit for these, so there is no extension at that level.  It is
just the backend driven extensions depending on POINTERS_EXTEND_UNSIGNED (not
defined at all, the usual case when ptr_mode == Pmode, 1 for zero extension, 0
for sign extension and -1 for special instructions to perform it).