This is the mail archive of the
mailing list for the GCC project.
Re: Re: [PATCH] Canonical types (1/3)
- From: "Doug Gregor" <doug dot gregor at gmail dot com>
- To: "Richard Kenner" <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 5 Dec 2006 10:57:48 -0500
- Subject: Re: Re: [PATCH] Canonical types (1/3)
- References: <firstname.lastname@example.org> <4574C3CA.email@example.com> <10612050227.AA08121@vlsi1.ultra.nyu.edu>
On 12/4/06, Richard Kenner <firstname.lastname@example.org> wrote:
> + if (TYPE_CANONICAL (to_type) != to_type)
> + TYPE_CANONICAL (t) =
> + build_pointer_type_for_mode (TYPE_CANONICAL (to_type),
> + mode, can_alias_all);
Minor issue: the "=" is on the wrong line.
> > + 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.