[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