This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Enable TBAA on anonymous types with LTO
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, ebotcazou at libertysurf dot fr, paul at codesourcery dot com
- Date: Tue, 30 Sep 2014 18:29:39 +0200
- Subject: Re: Enable TBAA on anonymous types with LTO
- Authentication-results: sourceware.org; auth=none
- References: <20140926191400 dot GB27278 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1409291019370 dot 20733 at zhemvz dot fhfr dot qr> <20140929153615 dot GB19673 at kam dot mff dot cuni dot cz> <542ABFA1 dot 1080102 at redhat dot com>
> On 09/29/2014 11:36 AM, Jan Hubicka wrote:
> >If C++ FE sets canonical type always to main variant, it should work.
> >Is it always the case?
>
> No. For a compound type like a pointer or function the canonical
> type strips all typedefs, but a main variant does not.
>
> >>> namespace {
> >>> struct B {};
> >>> }
> >>> struct A
> >>> {
> >>> void t(B);
> >>> void t2();
> >>> };
> >
> >Yep, A seems to be not anonymous and mangled as A. I think it is ODR violation
> >to declare such type in more than one compilation unit (and we will warn on
> >it). We can make it anonymous, but I think it is C++ FE to do so.
>
> Yes, it's an ODR violation. The FE currently warns about a field
> with internal type, and I suppose could warn about other members as
> well.
The testcase seems to get around without a warning for both G++ and clang
(at least without -Wall)
>
> >I really think that anonymous types are meant to not be accessible from other
> >compilation unit and I do not see why other languages need different rule.
>
> Agreed.
>
> >This does not work for types build from ODR types that are not ODR themselves.
>
> I'm not sure what you mean. In C++ the only types not subject to
> the ODR are local to one translation unit, so merging isn't an
> issue. Do you mean types from other languages?
Yes, Richard would like
namespace {
struct A {int a;};
}
to be considered with aliasing with
struct B {int b;};
in the other unit if that unit is built in C language (or any other than C++).
Honza
> Jason