[Bug lto/58084] [4.9 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The patch to "fix" this is issue is proposed at
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00078.html


> If a type is refered to by two functions it is by definition not local.  But
> as it references a local entity it is local.

> Note that you seem to have put the type local for RESULT_DECL but still
> have the global type used for the function type that hangs off the
> function decl.  That type also refers to the PARM_DECLs which are local, too
> now AFAIK.
While it was discussed in more generality the thread of
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00058.html , I will just add my
understanding to this particular problem here.

The type of RESULT_DECL was always local by tree_indexable predicate, since it
is variable sized and it reffers to local variable of the outer function in its
DECL_SIZE. The fact that RESULT_DECL was in global stream did not solve it.
The effect was that RESULT_DECL pushed another copy of the type into global
stream referring another copy of the local variable from global stream that
will never get unified with the real local variable in the local stream.  We do
not ICE because we compare types for equality between returned value and
returned type. Still the types are ill formed - we have three copies of the
type after streaming in (one global and one for each of the functions) and
three copies of the local variable (breaking one declaration rule).  We happen
to survive because we do not need the bad ones.

If we had another use of the type besides the returning we would get the same
problem even with global RESULT_DECL.  One can not write a testcase as for some
reason assignment of variable sized types is forbidden, while returning is
allowed.

The other ICE in thunks should be fixed by
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00078.html