https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122483
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org
--- Comment #12 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > (In reply to H.J. Lu from comment #7)
> > >
> > > It is done on purpose for C++. Otherwise, we get
> > >
> > > g++.dg/tm/pr46270.C
> > > g++.dg/tm/pr46567.C
> > > g++.dg/tm/pr47340.C
> > > g++.dg/tm/unsafe2.C
> > >
> > > See
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122428
> >
> > That does not mean it can't be different for different attributes on the
> > types :).
>
> But C++ front-end does this for all type-affecting attributes. There are
> no exceptions.
H.J., I noticed that the nocf_check definition has the affects_type_identity
field set to true. gcc/c-family/c-attribs.cc has:
{ "nocf_check", 0, 0, false, true, true, true,
handle_nocf_check_attribute, NULL },
where the field before handle_nocf_check_attribute is affects_type_identity.
I was wondering why this is the case / whether it is intentional? ISTM that:
1. The C/C++ front-ends shouldn't allow duplicate decls with different
incompatible types (overloading aside). E.g.:
void foo(void);
int foo(void);
is currently rejected by both the C and C++ front-ends.
2. Attributes which affect type identity (such as [[arm::streaming]]) should
not be ignored for the purposes of deciding whether decls are compatible.
Hence a possible way forward seems to be:
(i) Make nocf_check not affect type identity, which would seem to tie up with
the behaviour you're after here.
(ii) Make diagnose_mismatched_decls (and the corresponding place in the C++
front-end) reject decls which are mismatched based on attributes which affect
type identity.
What do you think? Also CCing front-end folks for an opinion.
