Canonical type nodes, or, comptypes considered harmful

[Gabriel Dos Reis]

"Doug Gregor" <doug.gregor@gmail.com> writes:

| 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.

I hope that is a short-term work-around.

| This will only be set
| true for cases where either GCC's internal representation or the
| language forces us into structural equality testing.

For function types, all C++ front-end maintainers agreed (some time
ago) that the front-end should move to a state where default arguments
and the like are moved out of the type notes, therefore enabling more
sharing.  I think Kazu did a premilinary good work there.

| 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).

I'm not worried about the C type system :-/

-- Gaby