This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR26763, pointer overflow
- From: Richard Guenther <rguenther at suse dot de>
- To: gcc-patches at gcc dot gnu dot org
- Cc: joseph at codesourcery dot com, roger at eyesopen dot com
- Date: Mon, 3 Apr 2006 13:09:50 +0200 (CEST)
- Subject: Re: [PATCH] Fix PR26763, pointer overflow
- References: <Pine.LNX.4.64.0604031048460.32350@t148.fhfr.qr>
On Mon, 3 Apr 2006, Richard Guenther wrote:
>
> This patch addresses PR26763 which is another case where we end up
> with an expression relying on pointer overflow being defined. I have
> convinced myself that it is a bad idea to assume anything about pointer
> overflow, so the only thing we can safely fold is equality and inequality.
>
> Another possibility would be to split the cases of ADDR_EXPR
> (ARRAY_REF(..)) from the cases that only look like these again and rely
> on the array domain for folding. (This also hints at possible problems
> with the mem-refs as array-ref thing)
>
> Can anyone specify the conditions in where we are allowed to do
> &a[i] CMP &a[j] -> i CMP j conversion and in which cases
> a +- i CMP a +- j -> i CMP j ? (note that i and j are pointers
> in the latter case and the addition/subtraction is either signed or
> unsigned dependent on the signedness of pointers)
>
> So, as a stop-gap for now, ok for mainline? (I'll make sure to XFAIL
> valid transformations we no longer perform in the testcases that are
> around there)
There are no additional failures with this patch. Bootstrapped and
regtested on x86_64-unknown-linux-gnu.
Richard.