This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/85046] [8 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'
- From: "nathan at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 26 Mar 2018 11:09:44 +0000
- Subject: [Bug c++/85046] [8 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'
- Auto-submitted: auto-generated
- References: <bug-85046-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85046
--- Comment #3 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Created attachment 43758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43758&action=edit
another example
I've further altered the testcase. This one ICEs at #3 all the way back to
gcc-5 (at least). Notice it gives no error on lines #1 or #2, at least one of
those is bogus.
Line #1 either implicitly creates union g inside c()::q, or is an error (I need
to check the std carefully, but my recollection is that inside a struct
definition only 'union g;' forward declares a union. ). If that recollection
is wrong, and #1 is ok. then #2 is an error, because we have to tagged types
'g' inside c()::q.
What's happening is that the the xref_tag for 'union q' inside c()::q has
ts_global for the scope -- so it looks in outer scopes. But this also injects
it into an outer scope when we don't find it. That's wrong. Our lazy binding
level caching machinery gets confused and scroggs the binding stack, leading to
bad reuse. In some cases that bad reuse was hidden by the existence of a
namespace-scope binding onto IDENTIFIER_BINDING. That doesn't exist any more.
So we ICE in some more cases.
I still think this is ICE on invalid, but it's not error-recovery.