Trying to backport alias fix to 4.2

Trying to backport alias fix to 4.2

[Ned Gill]

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.


Thanks,
Ned.

-- 
 

Re: Trying to backport alias fix to 4.2

[Richard Guenther]

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.
>
> --
>
>
>

Re: Trying to backport alias fix to 4.2

[Ned Gill]

On Tue, 18 Aug 2009 10:14:37 +0100, Richard Guenther  
<richard.guenther@gmail.com> wrote:

> 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.

Thanks for the quick reply.  Could you expand a little - should I be  
looking at tree-ssa-alias.c or tree-ssa-pre.c?  I'm not really familiar  
with this part of the compiler.  What do you mean by "constraint" in this  
context?

Thanks,
Ned.

--
 

Re: Trying to backport alias fix to 4.2

[Richard Guenther]

On Tue, Aug 18, 2009 at 11:32 AM, Ned Gill<thomas.gill@csr.com> wrote:
> On Tue, 18 Aug 2009 10:14:37 +0100, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>
>> 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.
>
> Thanks for the quick reply.  Could you expand a little - should I be looking
> at tree-ssa-alias.c or tree-ssa-pre.c?  I'm not really familiar with this
> part of the compiler.  What do you mean by "constraint" in this context?

No, the fix would be to tree-ssa-structalias.c somewhere in
handle_lhs_call (or find_func_aliases) - sorry, I don't have a 4.2 tree
around.  In the context you should see what a constraint is.

Richard.

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

Re: Trying to backport alias fix to 4.2

[Ned Gill]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]


FWIW, I'm still looking at this on and off.  I beleive the pure function  
was a red herring, as this example also does the wrong thing:

extern int z;

int foo(int *y)
{
     z = 1;
     *y = 0;
     return z;  // returns 1, even though y could point to z :(
}

Not much joy tracking it down as yet.  I've attached the alias information  
tree dump in case anyone fancies a look.  It looks ok to me, but I don't  
really understand it fully.

As a reminder: this bug is fixed from r119502 on trunk. I'd like to fix it  
on 4.2.x.


Ned.


-- 
 

[-- Attachment #2: bbb.c.030t.alias1 --]
[-- Type: application/octet-stream, Size: 2486 bytes --]


;; Function foo (foo)

Points-to analysis

Constraints:

ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
ESCAPED_VARS = *ESCAPED_VARS
y = ESCAPED_VARS
NONLOCAL?5? = ESCAPED_VARS
ESCAPED_VARS = &NONLOCAL?5?
ESCAPED_VARS = &NONLOCAL?5?
ESCAPED_VARS = D.1497_4

Collapsing static cycles and doing variable substitution:

Solving graph:

Points-to sets

NULL = { }
ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
ESCAPED_VARS = { NONLOCAL?5? }
y = same as ESCAPED_VARS
NONLOCAL?5? = { NONLOCAL?5? }
D.1497_4 = { }

foo: Total number of aliased vops: 2

Referenced variables in foo: 7

Variable: z, UID 1493, int, is aliased, is addressable, is global, call clobbered, default def: z_1

Variable: y, UID 1494, int *, symbol memory tag: SMT?6?, default def: y_3

Variable: <retval>, UID 1496, int

Variable: D.1497, UID 1497, int

Variable: NONLOCAL?5?, UID 1505, void, is aliased, is addressable, is global, call clobbered

Variable: SMT?6?, UID 1506, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? z }

Variable: NMT?7?, UID 1507, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? }



Pointed-to sets for pointers in foo

y_3, name memory tag: NMT?7?, is dereferenced, its value escapes, points-to vars: { NONLOCAL?5? }


Flow-insensitive alias information for foo

Aliased symbols

z, UID 1493, int, is aliased, is addressable, is global, call clobbered, default def: z_1
NONLOCAL?5?, UID 1505, void, is aliased, is addressable, is global, call clobbered
SMT?6?, UID 1506, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? z }
NMT?7?, UID 1507, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? }

Dereferenced pointers

y, UID 1494, int *, symbol memory tag: SMT?6?, default def: y_3

Symbol memory tags

SMT?6?, UID 1506, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? z }


Flow-sensitive alias information for foo

SSA_NAME pointers

y_3, name memory tag: NMT?7?, is dereferenced, its value escapes, points-to vars: { NONLOCAL?5? }

Name memory tags

NMT?7?, UID 1507, int, is addressable, is global, call clobbered, may aliases: { NONLOCAL?5? }



Symbols to be put in SSA form

z NONLOCAL?5? SMT?6? NMT?7? 

Incremental SSA update started at block: 0

Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)



foo (y)
{
  int D.1497;

<bb 2>:
  z = 1;
  *y_3 = 0;
  D.1497_4 = z;
  return D.1497_4;

}

Re: Trying to backport alias fix to 4.2

[Richard Guenther]

On Wed, Aug 26, 2009 at 12:50 PM, Ned Gill<thomas.gill@csr.com> wrote:
>
> FWIW, I'm still looking at this on and off.  I beleive the pure function was
> a red herring, as this example also does the wrong thing:
>
> extern int z;
>
> int foo(int *y)
> {
>    z = 1;
>    *y = 0;
>    return z;  // returns 1, even though y could point to z :(
> }
>
> Not much joy tracking it down as yet.  I've attached the alias information
> tree dump in case anyone fancies a look.  It looks ok to me, but I don't
> really understand it fully.
>
> As a reminder: this bug is fixed from r119502 on trunk. I'd like to fix it
> on 4.2.x.

Sorry, you are hitting some major latent problems there.  The
affected piece got a complete rewrite for 4.3, an isolated fix is likely
not easily possible.  The above problem is that NONLOCAL is
broken - it should have used the SMT for anything instead.

The code in 4.4 is somewhat sane, still corner cases are incorrect
there, hopefully fixed on trunk.

Richard.

>
> Ned.
>
>
> --
>