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
