This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/85046] [8 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]