https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #8)
> (In reply to Jan Hubicka from comment #2)
> > 2.ii:62:3: warning: ‘ml_bssnrest_’ violates the C++ One Definition Rule
> > [-Wodr]
> > 62 | } ml_bssnrest_;
> > | ^
> > 1.ii:2:8: note: type ‘struct <anon>’ defined in anonymous namespace cannot
> > match across the translation unit boundary
> > 2 | struct {
> > | ^
> > 2.ii:2:15: note: the incompatible type defined in another translation unit
> > 2 | extern struct {
> > | ^
> > 1.ii:62:3: note: ‘ml_bssnrest_’ was previously declared here
> > 62 | } ml_bssnrest_;
> > | ^
> >
> > Now I wonder why C++ FE makes the struct anonymous namespace when it is
> > declared with extern "C".
> > I have checked that type_in_anonymous_namespace_p(prevailing_type) returns
> > true because mangled name is <anon> which comes from C++ FE.
> >
> > I will check in the patch to avoid ICE. Jason, can you please look if it is
> > correct to consider these types anonymous?
>
> They aren't in the anonymous namespace, but they are themselves anonymous,
> so they have no linkage. The standard says,
>
> A type without linkage shall not be used as the type of a variable or
> function with external linkage unless
> — the entity has C language linkage (7.5), or
> — the entity is declared within an unnamed namespace (7.3.1), or
> — the entity is not odr-used (3.2) or is defined in the same translation
> unit.
>
> Here 1.ii is OK under the third bullet, and 2.ii under the first bullet.
> Within extern "C" I guess we need to do structural comparison for anonymous
> types rather than rely on the ODR.
Honza?
