[Bug c++/124485] [16 Regression][modules] Conflicting declaration 'struct __cxxabiv1::__class_type_info'

[nshead at gcc dot gnu.org]

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

Nathaniel Shead <nshead at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[modules] Conflicting       |[16 Regression][modules]
                   |declaration 'struct         |Conflicting declaration
                   |__cxxabiv1::__class_type_in |'struct
                   |fo'                         |__cxxabiv1::__class_type_in
                   |                            |fo'
   Last reconfirmed|                            |2026-03-14
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=122053
   Target Milestone|---                         |16.0
           Keywords|                            |ice-on-valid-code

--- Comment #1 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Confirmed.  Reduced:

  // a.cpp
  module;
  namespace __cxxabiv1 {
    struct __class_type_info {};
  }
  struct type_info {
    void __do_upcast(__cxxabiv1::__class_type_info);
  };
  export module foo;
  type_info t;

  // b.cpp
  import foo;
  struct Type {
    virtual ~Type() {}
  };

This regressed with the fix for PR122053,
r16-4228-gfa6544ef5f50a824cabeda4906453d4545fbf66f. 

The issue is that we have a workaround in 'lookup_elaborated_type' to try and
find any existing mergeable declarations of '__class_type_info' and bail from
there to prevent this exact ICE despite us not implementing PR99000 yet.  But
it doesn't kick in here because when we do 'lookup_elaborated_type' we haven't
loaded the declaration yet (and it's GMF, so it has no binding) so we attempt
to build our own type.

But when we go to 'pushtag' we do a 'lazy_load_pendings' call to find any
pending entities attached to the '__class_type_info' name, which ends up
pulling out the class type's definition.  And then in 'check_module_override'
we call 'duplicate_decls' on the entity and things go awry, because of PR99000.

Two possible fixes:

- The narrow fix would be to do a 'lazy_load_pendings' to find any declarations
from 'tinfo_base_init' before attempting to do 'xref_tag', which would allow us
to find the delaration.  But this is hard because we don't actually have a
declaration yet to get the pending key from, so we'd need to add a new API to
manually construct it.

- Alternatively, we could move the special-casing of the ABI types to
'check_module_override'.  Eventually this is probably where we should handle
textual redefinitions anyway, through the duplicate_decls call, so maybe this
is the better approach.