This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR c++/26693, second attempt


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]