----------------------------------------- struct S { int i; }; template<int S::*p> struct X {}; template <class T> struct Foo { X<&S::i> x; }; template struct Foo<void>; ----------------------------------------- ptrmem7.C:13: internal compiler error: Segmentation fault Please submit a full bug report, Regression on the mainline wrt 3.3 branch. Can anybody run the regression hunter script on this?
Let me add, I suspect of this patch: http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02281.html 2003-07-22 Mark Mitchell <mark@codesourcery.com> Eliminate use of POINTER_TYPE for pointers-to-members. [...]
Phil's regression hunter says: : Search converges between 2003-07-07-trunk (#336) and 2003-07-08-trunk (#337). At first we get: input.cc:10: internal compiler error: in lookup_member, at cp/search.c:1214 One day later we get a segfault.
We segfault because the SCOPE_REF &S::i does not have a type computed at the time convert_nontype_argument is called. I tried to change build_scope_ref so that it does creat SCOPE_REFs only for type-dependent expressions, and rework create_nontype_argument accordingly, but with no luck. Mark, there are two patches of yours in those days affecting non-dependent SCOPE_REFs, and a few days later you reworked totally the pointer-to-members. Notice that this is failure caught by g++.dg/template/ptrmem7.C, which I recently added to the mainline, so we don't need another testcase. If you give me a hint where to look, I can try fixing this myself.
I think we should preserve the SCOPE_REF because correct access checking of members in class hierarchy requires this. My idea would be putting the type information into it when it's not a dependent name.
(In reply to comment #4) > I think we should preserve the SCOPE_REF because correct > access checking of members in class hierarchy requires this. > My idea would be putting the type information into it when > it's not a dependent name. But since the whole expression "&S::i" is non-dependent, we could/should perform access checking at parsing time (following the two-stage lookup rules) and construct an OFFSET_REF directly, just like we do outside a template. Where am I wrong?
You can look at the example in section 11.5. In that example, &B::i and &D::i are really the same member but with different access. If we resolve the name early, the scope (whether it is 'B' or 'D') information is lost. And in case of those qualified-id in template, we cannot sure about its access until instantiation time (like when the function 'fr' in the example is changed to a template, and only some specialization is a friend class 'D2').
Thanks for the explanation Kriang, I'm still trying to make a sense out of all these trees. It turned out I was fighting windmills, the problem is that we were trying to tsubst too early. I'm testing this patch right now, it fixes the regression and I'm confident it's doing the right thing. Index: pt.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/cp/pt.c,v retrieving revision 1.791 diff -c -p -r1.791 pt.c *** pt.c 24 Oct 2003 07:59:40 -0000 1.791 --- pt.c 21 Nov 2003 23:46:26 -0000 *************** convert_template_argument (tree parm, *** 3549,3555 **** if (invalid_nontype_parm_type_p (t, complain)) return error_mark_node; ! if (!uses_template_parms (arg) && !uses_template_parms (t)) /* We used to call digest_init here. However, digest_init will report errors, which we don't want when complain is zero. More importantly, digest_init will try too --- 3549,3556 ---- if (invalid_nontype_parm_type_p (t, complain)) return error_mark_node; ! if (!uses_template_parms (arg) && !uses_template_parms (t) ! && TREE_TYPE (arg)) /* We used to call digest_init here. However, digest_init will report errors, which we don't want when complain is zero. More importantly, digest_init will try too
mine for now.
I am not sure the patch is legit, and I can't find where I should calculate the SCOPE_REF's type. I leave this to someone more expert.
ice-on-valid-code, so should be P1
Will investigate.
Any progress Kriang?
A patch should be ready within a few days. I have a working solution but some issue remain unanswered. It needs some more testing to make sure it's really correct.
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01785.html
Subject: Re: [3.4/3.5 regression] Segfault in convert_nontype_argument On Sun, 2004-01-18 at 05:14, lerdsuwa at gcc dot gnu dot org wrote: > ------- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-01-18 13:14 ------- > Patch submitted: > > http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01785.html I'm not comfortable with this patch yet, but maybe I just need to look at it harder. I'll do that soon. Thanks,
Subject: Re: [3.4/3.5 regression] Segfault in convert_nontype_argument lerdsuwa at gcc dot gnu dot org wrote: >------- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-01-18 13:14 ------- >Patch submitted: > >http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01785.html > > > I think this patch is mostly OK -- but I don't like the bits in convert_nontype_argument. Why can't whatever access checking needs to be done be done at that point? Can you provide an example explaining why it's necessary to do what's being done there? Thanks,
An example why access checking has to be done later can be seen from the testcase non-dependent9.C in the patch. In the following code: template <class T> void fr () { ... X<&D2::i> x1; // { dg-error "context" } ... we are parsing '&D2::i' and call 'convert_nontype_argument' to see if the argument is valid. We can't compute access yet because the function 'fr' is still a template. We have to wait until 'fr' is instantiated to see if this particular specialization is a friend of 'D2'. The check is done in 'tsubst_qualified_id' during template instantiation.
The segfault is now gone (in 3.4 and mainline) - fixed by Mark's patch http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02882.html However, the testcases 2 and 4 of Kriang's patch do compile although they should issue an error. Just for referecnce, here's number 2: ========================================= struct S { char i; }; template<int S::*p> struct X {}; template <class T> struct Foo { X<&S::i> x; // { dg-error "convert|no type" } }; ========================================= This is still a regression.
Patch need to be updated after Mark's fold_non_dependent_expr change. Will get to this after I am finished with PR c++/13635.
Here is a simple test not involving any templates. This invalid code is rejected by gcc 3.2.2, but compiles with gcc-ss-3_4-20040211 struct B { int b; }; struct D : public B { int d; }; int D::* pd = &D::d; int B::* pb = pd; // <-- this should fail
Revised patch available: http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02612.html This fixes testcase 2 and 4 but not access checking testcase. That will be handled separately.
Mark, we need a review for this patch. It is a *partial* patch, but it is a first step in getting this regression closed.
This patch isn't quite right. Most of the changes look good, but in type_dependent_expression_p, we should move the existing unknown_type_node code above the SCOPE_REF code. Then, the uknown_type_node code should be updated to handle SCOPE_REF.
OK, a revised patch should be ready in within a few days.
Postponed until GCC 3.4.1.
Revised patch for 3.4.1 and mainline: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01897.html
Remove myself from bug assignment for now. Will be away May 27-June 12. No time to deal with this for GCC 3.4.1.
This patch is OK for 3.4.1. Jason, since you took an interest here and Kriang is away, would you please apply this? Thanks, -- Mark
Subject: Bug 13092 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: jason@gcc.gnu.org 2004-06-01 15:48:55 Modified files: gcc/cp : ChangeLog cxx-pretty-print.c error.c init.c pt.c Log message: PR c++/13092 * init.c (build_offset_ref): Build SCOPE_REF with non-null TREE_TYPE for non-dependent names. * pt.c (type_dependent_expression_p): Handle SCOPE_REF with unknown_type_node as its TREE_TYPE. * cxx-pretty_print.c (pp_cxx_unqualified_id): Handle BASELINK. * error.c (dump_decl) <SCOPE_REF case>: Use pp_expression. (dump_expr) <SCOPE_REF case>: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.112&r2=1.3892.2.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cxx-pretty-print.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.13&r2=1.13.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.241.4.3&r2=1.241.4.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.356.2.10&r2=1.356.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.27&r2=1.816.2.28
Subject: Bug 13092 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2004-06-01 15:51:59 Modified files: gcc/cp : ChangeLog call.c cxx-pretty-print.c error.c init.c pt.c Log message: PR c++/13092 * init.c (build_offset_ref): Build SCOPE_REF with non-null TREE_TYPE for non-dependent names. * pt.c (type_dependent_expression_p): Handle SCOPE_REF with unknown_type_node as its TREE_TYPE. * cxx-pretty_print.c (pp_cxx_unqualified_id): Handle BASELINK. * error.c (dump_decl) <SCOPE_REF case>: Use pp_expression. (dump_expr) <SCOPE_REF case>: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4074&r2=1.4075 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.477&r2=1.478 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cxx-pretty-print.c.diff?cvsroot=gcc&r1=1.19&r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.250&r2=1.251 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.371&r2=1.372 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.857&r2=1.858
Subject: Bug 13092 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2004-06-01 15:54:34 Added files: gcc/testsuite/g++.dg/template: non-dependent10.C non-dependent7.C non-dependent8.C non-dependent9.C Log message: PR c++/13092 * init.c (build_offset_ref): Build SCOPE_REF with non-null TREE_TYPE for non-dependent names. * pt.c (type_dependent_expression_p): Handle SCOPE_REF with unknown_type_node as its TREE_TYPE. * cxx-pretty_print.c (pp_cxx_unqualified_id): Handle BASELINK. * error.c (dump_decl) <SCOPE_REF case>: Use pp_expression. (dump_expr) <SCOPE_REF case>: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent10.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent8.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Jason -- Give that you applied the patch, does it not make sense to mark this PR as fixed? -- Mark
(In reply to comment #32) > Give that you applied the patch, does it not make sense to mark this PR as fixed? > -- Mark Mark, read comment #21, Kriang specifies that this patch is in fact partial, and that the access checking testcases available at http://gcc.gnu.org/ml/gcc- patches/2004-01/msg01785.html are still not working.
It looks like this patch generated the regression shown in PR 15875.
Subject: Re: [3.4/3.5 regression] Accepts invalid pointer-to-member conversion I've reverted this patch for now. Kriang, can you take a look at 15875? Thanks, Jason
Back from travel. Will look at PR15875 issue.
Thank you Kriang. This bug is really a can of worm :/
Postponed until GCC 3.4.2.
Updated patch available: http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01606.html
Kriang, I suppose you tested the testcase from PR 15875 too. If that works with the updated patch, you may want to commit the testcase as part of your patch. Also, does this take into account also the access checking testcases (re: comment #21)?
Yes, it passes the PR 15875 test. The failure is the same as in some of the added testcases so it's not included in the patch. This patch doesn't address access checking issue. I mentioned it because the first version of this patch contained both the fix to this PR and access checking problem. It will be opened as a separate PR.
This patch is OK for mainline. If it doesn't cause any problems there in a week, please apply it to the 3.4 branch as OK.
Subject: Bug 13092 CVSROOT: /cvs/gcc Module name: gcc Changes by: lerdsuwa@gcc.gnu.org 2004-07-18 12:37:57 Modified files: gcc/cp : ChangeLog cxx-pretty-print.c error.c init.c pt.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: non-dependent7.C non-dependent8.C non-dependent9.C non-dependent10.C Log message: PR c++/13092 * init.c (build_offset_ref): Build SCOPE_REF with non-null TREE_TYPE for non-dependent names. * typeck.c (build_x_unary_op): Handle non-dependent SCOPE_REF. * pt.c (type_dependent_expression_p): Handle SCOPE_REF with unknown_type_node as its TREE_TYPE. * cxx-pretty_print.c (pp_cxx_unqualified_id): Handle BASELINK. * error.c (dump_decl) <SCOPE_REF case>: Use pp_expression. (dump_expr) <SCOPE_REF case>: Likewise. * g++.dg/template/non-dependent7.C: New test. * g++.dg/template/non-dependent8.C: Likewise. * g++.dg/template/non-dependent9.C: Likewise. * g++.dg/template/non-dependent10.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4216&r2=1.4217 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cxx-pretty-print.c.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.256&r2=1.257 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.385&r2=1.386 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.887&r2=1.888 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.561&r2=1.562 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4014&r2=1.4015 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent7.C.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent8.C.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent9.C.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent10.C.diff?cvsroot=gcc&r1=1.2&r2=1.3
Mainline fixed.
The problem, mentioned as not fixed by my patch, is now in a separate bug report, PR16617. So this PR will be closed once my patch is applied to GCC 3.4 branch.
Subject: Bug 13092 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: lerdsuwa@gcc.gnu.org 2004-07-28 14:55:09 Modified files: gcc/cp : ChangeLog cxx-pretty-print.c error.c init.c pt.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: non-dependent7.C non-dependent8.C non-dependent9.C non-dependent10.C Log message: PR c++/13092 * init.c (build_offset_ref): Build SCOPE_REF with non-null TREE_TYPE for non-dependent names. * typeck.c (build_x_unary_op): Handle non-dependent SCOPE_REF. * pt.c (type_dependent_expression_p): Handle SCOPE_REF with unknown_type_node as its TREE_TYPE. * cxx-pretty_print.c (pp_cxx_unqualified_id): Handle BASELINK. * error.c (dump_decl) <SCOPE_REF case>: Use pp_expression. (dump_expr) <SCOPE_REF case>: Likewise. * g++.dg/template/non-dependent7.C: New test. * g++.dg/template/non-dependent8.C: Likewise. * g++.dg/template/non-dependent9.C: Likewise. * g++.dg/template/non-dependent10.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.135&r2=1.3892.2.136 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cxx-pretty-print.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.13.4.2&r2=1.13.4.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.241.4.6&r2=1.241.4.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.356.2.13&r2=1.356.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.33&r2=1.816.2.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.519.2.20&r2=1.519.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.237&r2=1.3389.2.238 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent8.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent10.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1
Fixed in 3.4 branch.