This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compatibility of structs/unions/enums in the middle end
Am Mittwoch, den 02.10.2019, 12:47 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 12:46 PM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin
> > <Martin.Uecker@med.uni-goettingen.de> wrote:
...
> > >
> > > In particular, the idea is to make structs (+ unions, enums)
> > > with the same tag and the same members compatible. The
> > > current C standards says that such structs are compatible
> > > between different TUs but not inside the same TU, which
> > > is very strange and - as pointed out by Joseph
> > > in DR314 - this leads to "interesting" scenarios
> > > where types across different TU cannot be partitioned
> > > into equivalence classes in a consistent way.
...
> > > I would appreciate any information about how to
> > > approach this.
> >
> > The frontend either needs to have the same internal
> > type representation for both or provide the middle-end
> > with unification of compatible types via the TYPE_CANONICAL
> > mechanism (that's what the C++ FE does in similar circumstances).
> >
> > That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT (st1))
> > == TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2))
> > (or requivalent TYPE_MAIN_VARIANT if that's already the case).
Yes, this is what I assumed from looking at the code. The problem
is that the front end would need to go over all types and set
TYPE_CANONICAL.
This seems easy to do on the fly whenever the front
end needs to compare types anyway, but this would not be enough
as also types which appear unrelated to the front end (e.g. two
types declared in separate local scopes) could be compatible.
To identify these types would require searching a data structure
of all such types in the front end every time a new tagged type
is created. This would not be too difficult to implement.
On the other hand, the situation with this propsoal for such types
is then very similar to any other complex type expressions which
need to compared structurally in the middle end. So what I am
wondering is whether it would be possible to do such comparisons
in the middle end also for tagged types?
Finally, how does LTO does it? It somehow also needs to unify
different tagged types? Could we reuse this mechanism somehow?
> Btw, for you example, how do you expect debug information to look like?
> Would there be two type definitions that are not related?
I don't know yet. This is why I am trying to implement it, to
figure out all these practical issues. How does it work now for
tagged types in different TUs that are compatible?
Best,
Martin