Re: Canonical type nodes, or, comptypes considered harmful

["Doug Gregor" <doug dot gregor at gmail dot com>]

On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
>
> | > Like when int and long have the same range on a platform?
> | > The answer is they are different, even when they imply the same object
> | > representation.
> | >
> | > The notion of unified type nodes is closer to syntax than semantics.
> |
> | I'm more than a little confused, then, as to what we are talking about
> | canonicalizing.  We already have only one pointer to each type, for example.
>
> yes, but it is not done systematically.  Furthermore, we don't unify
> function types -- because for some reasons, it was decided they would
> hold default arguments.

... and exception specifications, and some attributes that are really
meant to go on the declaration.

So, until we bring our types into line with C++'s type system, we're
going to have to retain some level of structural checking. Based on
Dale's suggestion, I'm inclined to add a new flag
"requires_structural_comparison" to every type. This will only be set
true for cases where either GCC's internal representation or the
language forces us into structural equality testing. For C++, I think
we're only forced into structural equality testing where GCC's
internal representation doesn't match C++'s view of type equality. For
C, it looks like array types like int[10] require structural equality
testing (but my understanding of the C type system is rather weak).

 Cheers,
 Doug