https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
void foo(int n)
{
  struct X { int a[n]; } a;
  struct Y { struct X *p; } b;
  static struct Y z;
}

shows that there's no clear boundary with the way we stream things given
'z' ends up in the symtab as global entity but it refers to a function-local
type.

With nested functions we'll easily fall into a similar trap I guess and
those would also make the above even more "complicated" by effectively
assigning z two different types? (one referencing 'n' directly and one
referencing it via the static chain -- which doesn't actually get 'n'
here)

int foo(int n)
{
  struct X { int a[n]; } a;
  struct Y { struct X *p; };
  static struct Y z;
  int bar(int i) { return z.p->a[i]; }
  z.p = &a;
  return bar(3);
}
int main() { return foo(5); }

just to mention these in the quest to get the "sharing" automagically
"correct".

So it looks like all types should be "global", even those refering to other
local entities.  We mostly promote things to "local" to optimize the WPA
tree merging phase and shrink the global section but it looks like the
"local" property is quite complicated and cannot be computed "locally"
when processing just one decls trees (global var or function).

Reply via email to