This is the mail archive of the
mailing list for the GCC project.
Re: Re: Re: [PATCH] Canonical types (1/3)
On 12/5/06, Richard Kenner <firstname.lastname@example.org> wrote:
> > > > + type = build_variant_type_copy (orig_type);
> > > > TYPE_ALIGN (type) = boundary;
> > > > + TYPE_CANONICAL (type) = TYPE_CANONICAL (orig_type);
> > >
> > > Eek. So, despite having different alignments, we consider these types
> > > "the same"? If that's what we already do, then it's OK to preserve that
> > > behavior, but it sure seems worrisome.
> > I'm concerned about that as well. I think we need a more precise
> > definition someplace of what is allowed to differ between two "variants"
> > of a type.
> I've been following whatever "comptypes" does, because that's the
> behavior canonical types need to mimic to provide the same behavior
> that we have now.
But the above creates a variant. That's what's confusing us.
Whenever we call build_variant_type_copy(orig_type), we build a new
type that is a "variant" or ORIG_TYPE, meaning that you can find the
new type from orig_type via TYPE_NEXT_VARIANT and you can find
orig_type from the new type via TYPE_MAIN_VARIANT.
Some variants are considered equivalent by comptypes, some aren't. For
instance, variants that change type qualifiers (const, volatile,
restrict, etc.) are NOT equivalent to the original type. Variants that
only change the name of the type (e.g., those variants that are
created for a typedef) are equivalent to the original type. So,
TYPE_NEXT_VARIANT basically contains a mish-mash of types that are
somehow related to the TYPE_MAIN_VARIANT, but may or may not be
It's also important to note that TYPE_NEXT_VARIANT does not even
contain all types that are equivalent to the main variant... it's just
a subset. For instance, say I have this code:
typedef int foo_t;
void f(int*, foo_t*);
int* and foo_t* will not occur in the same list of variants. They are
completely distinct type nodes, but comptypes will make them compare