[PATCH] Fix PR 29715, fold produces &a - 4
Richard Guenther
richard.guenther@gmail.com
Thu Mar 1 10:07:00 GMT 2007
On 3/1/07, Andrew_Pinski@playstation.sony.com
<Andrew_Pinski@playstation.sony.com> wrote:
> Hi,
> The problem here is that fold assumes that for ptr-- > a, fold assumes
> that the pointers will not overflow which is true but that is wrong as you
> can produce an extra overflow by doing this optimization if a was
> ((ptr_type)-1). This can also cause us to produce &a[-1] which is
> actually undefined in our IR.
>
> This patch removes the check that the type is a pointer and for the
> testcase in the bug report (which was found in the testsuite already), we
> produce better code now on the tree level in that we just generate a
> return 0 if we change the second return to f();. Also this fixes a
> regression on the ptr_plus_expr branch as we would try to generate a
> MINUS_EXPR with a Pointer type which is invalid on that branch.
>
> OK? Bootstrapped and tested on i686-linux-gnu on the trunk with no
> regressions.
This optimization doesn't look too useful at all now that we gimplify all this
post/preinc/decrement anyway. This is actually the only place where we look
at this operators in fold, so I suggest removing the whole
transformation instead.
Richard.
More information about the Gcc-patches
mailing list