"Doug Gregor" <[EMAIL PROTECTED]> writes: | On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis | <[EMAIL PROTECTED]> wrote: | > [EMAIL PROTECTED] (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
