Re: Trying to backport alias fix to 4.2

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Aug 18, 2009 at 10:39 AM, Ned Gill<thomas.gill@csr.com> wrote:
>
> I'm having a problem with code like the following on all 4.2.x versions of
> gcc (at least on intel and with my port):
>
> unsigned z = 1;
> unsigned *foo()
> {
> ? ?return &z;
> }
>
> int main(void)
> {
> ? ?z = 1;
> ? ?*foo() = 0;
> ? ?return z;
> }
>
> When optimisation is enabled, but inlining disabled (-O1 for example) the
> compiler appears to fail to recognise that z clobbered by *foo()=0, and
> produces code that returns a constant 1. ?The problem appears to be caused
> by foo being marked pure; if I move foo to another compilation unit, to
> problem goes away unless I mark the prototype with __attribute__((pure)).
> ?Also the problem goes away if I add a side-effect to foo. ?Looking at the
> tree dumps reveals that this problem appears in the FRE pass - although I'd
> guess that the problem could well originate in the earlier alias analysis
> pass.
>
> This problem is fixed in 4.3. ?A binary search through trunk GCC led me to
> revision 119502 (Daniel Berlin, 2006-12-04). ?However, it doesn't look like
> it's possible to back-port this change to 4.2, because of the intervening
> changes to the files involved. ?I naively attempted to patch across the
> relitively simple changes to tree-ssa-alias.c in 119502, but not suprisingly
> that didn't help on its own.
>
> Does anyone recognise this problem? ?Any help tracking down the cause of the
> problem would be very gratefully received - if nothing else I'll have to
> re-fix the problem in 4.2. ?However, my experience hacking the tree passes
> is pretty much zero :(
>
> In the long run I can upgrade to 4.3 or 4.4. ?However, updating my port and
> re-validating it is a fair amount of work that I'm not keen to tackle
> immediately.

It sounds like a bug in points-to analysis where it doesn't correctly
handle return values of pure/const functions.  I would just
add a constraint from anything to the lhs of the call to fix it.

(Note 4.2 and even 4.3 are completely wrong in what they are doing
there).

Richard.

>
> Thanks,
> Ned.
>
> --
>
>
>