Bug 26608 - address of local variables are said to escape even though it is obvious they don't
address of local variables are said to escape even though it is obvious they ...
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.2.0
: P3 enhancement
: 4.3.0
Assigned To: Not yet assigned to anyone
: alias, missed-optimization
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-08 18:59 UTC by Andrew Pinski
Modified: 2009-04-03 12:24 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-09-12 06:37:43


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2006-03-08 18:59:57 UTC
Testcase:
int *d1;
int g(int *b)
{
  d1 = b;
}
int f(int a, int b, int c)
{
  int i, j;
  int *d;
  if (a)
    d = &i;
  else
    d = &j;
  i = 2;
  j = 3;
  g(&b);
  if (i!=2)
   link_error();
  if (j!=3)
   link_error();
  return *d;
}
int main(void)
{
  f(1, 2,3);
  return 0;
}

This should link with optimize but right now i and j are said to be call clobbered for some reason.
Comment 1 Daniel Berlin 2006-03-08 19:44:01 UTC
Subject: Re:   New: address of local variables
	are said to escape even though it is obvious they don't

On Wed, 2006-03-08 at 18:59 +0000, pinskia at gcc dot gnu dot org wrote:
> Testcase:
> int *d1;
> int g(int *b)
> {
>   d1 = b;
> }
> int f(int a, int b, int c)
> {
>   int i, j;
>   int *d;
>   if (a)
>     d = &i;
>   else
>     d = &j;
>   i = 2;
>   j = 3;
>   g(&b);
>   if (i!=2)
>    link_error();
>   if (j!=3)
>    link_error();
>   return *d;
> }
> int main(void)
> {
>   f(1, 2,3);
>   return 0;
> }
> 
> This should link with optimize but right now i and j are said to be call
> clobbered for some reason.

What does the dump say.
My guess is that it believes that they are returned from the call, even
though they are not.

> 
> 

Comment 2 Andrew Pinski 2006-03-08 19:47:44 UTC
Variable: i, UID 1520, int, is aliased, is addressable, default def: i_3

Variable: j, UID 1521, int, is aliased, is addressable, default def: j_5

Variable: b, UID 1516, int, is aliased, is addressable, call clobbered (, passed to call )

Variable: SMT.30, UID 1569, int, is addressable, call clobbered (, passed to call ), may aliases: { i j b }

Hmm, it does not say why i and j are thought to be call clobbered but it looks like it is because the SMT is call clobbered.
Comment 3 Andrew Pinski 2006-09-12 06:37:43 UTC
Confirmed.
Comment 4 Richard Biener 2009-04-03 12:24:13 UTC
Works with 4.3.  Very similar to PR23086.