This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Re: Re: [PATCH] Canonical types (1/3)


On 12/5/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> 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
> equivalent.

The issue is what does "somehow related" mean.  In the past, I didn't think
that two types that had different alignments were consider sufficiently
related to have the same TYPE_MAIN_VARIANT.  So it seems wrong to have that
happen now.

It's always been happening; I haven't changed this at all. I'm just modeling what the system does now, and grafting canonical types on top of it. We can fix this system (Mark's proposal is, I think, the right way to do this), and I'm all for it. But we shouldn't do that as part of canonicalizing types.

For reference, the part of the patch that Mark was originally
referring to looks like this:

-      type = build_variant_type_copy (type);
+      tree orig_type = type;
+      type = build_variant_type_copy (orig_type);
      TYPE_ALIGN (type) = boundary;
+      TYPE_CANONICAL (type) = TYPE_CANONICAL (orig_type);

So, I've only added the TYPE_CANONICAL bits and introduced the new
variable orig_type.

 Cheers,
 Doug


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]