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] |
Hello, In this PR, the problem is that we are adding typedefs (needing access checking) used in template definitions to the wrong TEMPLATE_DECL for access check. Some TEMPLATE_DECL thus end up having unrelated typedefs, so some unrelated access check is happening at template instantiation time leading to dubious errors at compilation time. We initially wanted to append the typedef to the TEMPLATE_DECL of the most specialized template in which the said typedef was being used. Unfortunately, it appears that some templates don't have any associated TEMPLATE_DECL. For instance, partial class specialization don't have any associated TEMPLATE_DECL. Function templates don't have that "problem". For class templates this patch stores the typedefs needing access checking to the associated RECORD_TYPE. It just appends the list of typedefs to the template_info list node. For function template the patch stores the typedefs in the associated TEMPLATE_DECL, just as what was being done before. Also, during class template instantiation, the patch sets input_location to the source location of the most specialized template definition that is being instantiated, rather than to the source location of the most generic template definition. This fixes a source location bugglet uncovered by the typedef20.C test accompanying the patch. This patch bootstraps and passes g++ and libstdc++ regtests on trunk. I am running a full bootstrap/regtest at the moment. Would it be okay to commit to trunk assuming it passes full bootstrap ? Thanks. -- Dodji Seketeli Red Hat, Inc
Attachment:
gcc-PR40007-patch-2.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |