[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCH] PR c++/26693, second attempt
From:       "H.J. Lu" <hjl.tools () gmail ! com>
Date:       2010-02-28 0:10:38
Message-ID: 6dc9ffc81002271610l23862c1ds56a11be7886d22c1 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jan 12, 2010 at 9:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Apr 13, 2009 at 1:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Apr 1, 2009 at 6:48 AM, Dodji Seketeli <dodji@redhat.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hello,
>>>
>>> This is a second attempt at fixing PR c++/26693.
>>> The previous one that I submitted at
>>> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00797.html did cause
>>> regressions in libstd++ and java.
>>>
>>> There we several causes to these regressions:
>>>
>>> 1/ The patch uncovered a problem that was reported at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310. Jason did fix it.
>>>
>>> 2/ In retrieve_specialization, we try to look up specializations of
>>> template typedefs  DECL_TEMPLATE_INSTANTIATIONS (tmpl), assuming tmpl is
>>> a template.
>>>
>>> 3/ We were not fixing up type variants in xref_basetypes. That was
>>> causing e.g. instantiate_class_template to create instances of template
>>> for which the typedef type variants were not having their BINFO properly
>>> set.
>>>
>>> Issues 2 and 3 are addressed in the attached opus of the patch.
>>>
>>> I did a full bootstrap/regtest for c,c++,java,objc,objc++ on trunk, for
>>> x86_64.
>>>
>>> OK for trunk ?
>>>
>>> Dodji.
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>> Comment: Using GnuPG with Remi - http://enigmail.mozdev.org
>>>
>>> iEYEARECAAYFAknTcLwACgkQPejI7lrem2FSDwCgvV1IQD/y+2GcDOrkh6J0VL7Z
>>> YegAnjw0GgYh0Wj/BJfg/Y3mAkEh3zjX
>>> =rCqs
>>> -----END PGP SIGNATURE-----
>>>
>>> commit 079f3649e847db2e9a91ef687927f02bbad61f2c
>>> Author: Dodji Seketeli <dodji@redhat.com>
>>> Date:   Tue Mar 31 10:27:57 2009 +0200
>>>
>>>    Candidate fix for PR C++/26693
>>>
>>>    gcc/ChangeLog:
>>>    2009-02-26  Dodji Seketeli  <dodji@redhat.com>
>>>
>>>        PR c++/26693
>>>        * c-decl.c: (clone_underlying_type): Move this ...
>>>        * c-common.c (set_underlying_type): ... here.
>>>        Also, make sure the function properly sets TYPE_STUB_DECL() on
>>>        the newly created typedef variant type.
>>>        * c-common.h (is_typedef_decl, set_underlying_type): Declare ...
>>>        * c-common.c (is_typedef_decl, set_underlying_type): ... new entry points.
>>>
>>>    gcc/cp/ChangeLog:
>>>    2009-02-26  Dodji Seketeli  <dodji@redhat.com>
>>>
>>>        PR c++/26693
>>>        * decl2.c (grokfield): when a typedef appears in a
>>>        class, create the typedef variant type node for it.
>>>        (save_template_attributes): Creating typedef variant type node
>>>         here is now useless.
>>>        * decl.c (grokdeclarator): If the typedef'ed struct/class was
>>>        anonymous, set the proper type name to all its type variants.
>>>        (xref_basetypes) : Fixup the variant types after setting
>>>        TYPE_BINFO on REF.
>>>        * name-lookup.c (pushdecl_maybe_friend): Reuse the
>>>        set_underlying_type function to install typedef variant types.
>>>        * cp-tree.h (MEMBER_TYPES_NEEDING_ACCESS_CHECK): New template accessor
>>>        macro.
>>>        (append_type_to_template_for_access_check): New entry points.
>>>        * semantics.c (check_accessibility_of_qualified_id):
>>>        When a typedef that is a member of a class appears in a template,
>>>        add it to the template. It will be ...
>>>        * class.c (finish_struct_bits): Split type variant fixup into ...
>>>        (fixup_type_variants): A new entry point.
>>>        * pt.c (instantiate_class_template, instantiate_template ): ... access
>>>        checked at template instantiation time.
>>>        (resolve_type_name_type): The type name should be the name of the
>>>        main type variant.
>>>        (retrieve_specialization): Specializations of template typedefs aren't
>>>        to be looked up in DECL_TEMPLATE_INSTANTIATIONS (tmpl).
>>>        (append_type_to_template_for_access_check): New entry point.
>>>        (tsubst_decl): For typedefs, build the variant type from the correct
>>>        original type.
>>>        (get_class_bindings): Fix function comment.
>>>        (perform_typedefs_access_check): New entry point.
>>>
>>>    gcc/testsuite/ChangeLog:
>>>    2009-02-26  Dodji Seketeli  <dodji@redhat.com>
>>>
>>>        PR c++/26693
>>>        * g++.dg/template/typedef11.C: New test.
>>>        * g++.dg/template/typedef12.C: Likewise.
>>>        * g++.dg/template/typedef13.C: Likewise.
>>>        * g++.dg/template/typedef14.C: Likewise.
>>>        * g++.dg/template/typedef15.C: Likewise.
>>>        * g++.dg/template/typedef16.C: Likewise.
>>>        * g++.dg/template/sfinae3.C: Compile this pedantically.
>>>        The only errors expected should be the one saying the typedef is ill
>>>        formed.
>>>        * g++.old-deja/g++.pt/typename8.C: Likewise.
>>>        * g++.dg/template/access11.C: Update this.
>>>
>>>    libstdc++-v3/ChangeLog:
>>>    2009-02-26  Dodji Seketeli  <dodji@redhat.com>
>>>
>>>        * include/ext/bitmap_allocator.h: the typedefs should be made public
>>>        if we want them to be accessible. This has been revealed by the patch
>>>        that fixes PR c++/26693 in g++.
>>>
>>
>> This caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
>>
>
> This also caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42713
>

This also caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43206


-- 
H.J.

[prev in list] [next in list] [prev in thread] [next in thread]