This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fwd: [PATCH] Fix may_alias canonical types regression
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Doug Gregor <doug dot gregor at gmail dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 06 Oct 2008 09:26:22 -0700
- Subject: Re: Fwd: [PATCH] Fix may_alias canonical types regression
- References: <24b520d20809232259r3fc0ea95l85d8ed50010fc7bc@mail.gmail.com> <24b520d20809251053l752bf76aj76a3319432a35dab@mail.gmail.com> <48DD7B11.1070600@codesourcery.com> <24b520d20809270755p8ca2d83u4370c40dbb9bc1b9@mail.gmail.com> <48DFC628.9020108@codesourcery.com> <24b520d20810031526i7fc0664j9a15e109ca151344@mail.gmail.com>
Doug Gregor wrote:
> 2008-10-01 Douglas Gregor <doug.gregor@gmail.com>
>
> PR c++/37553
> * tree.c (build_type_attribute_qual_variant): Hash on the
> unqualified type, and don't overwrite an existing
> (type_hash_eq): Make the TYPE_NAME of the types significant, to
> allow distinguishing between wchar_t and its underlying type. This
> also means that we'll retain a little more typedef information.
>
> 2008-10-01 Douglas Gregor <doug.gregor@gmail.com>
>
> PR c++/37553
> * g++.dg/ext/alias-canon2.C: New.
This seems sensible. However, I think it would be useful to measure the
memory footprint of GCC with this change on some big C++ code.
(libstdc++ or Boost++ or some such). DECLs are big, and if we have a
whole lot more of them, we might be unhappy, and want to look for
another way to solve this. So, would you please measure and report?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713