Created attachment 27203 [details] preprocessed source seen with 4.6 and 4.7 branches, and trunk on i686-linux-gnu $ gcc -c -g part-combine-iterator.ii part-combine-iterator.cc: In member function 'virtual void Part_combine_iterator::derived_mark() const': part-combine-iterator.cc:173:40: internal compiler error: in cp_build_indirect_ref, at cp/typeck.c:2836 Please submit a full bug report, with preprocessed source if appropriate.
Created attachment 27204 [details] unincluded testcase 4.4 rejects it: part-combine-iterator.cc: In member function 'virtual void Part_combine_iterator::derived_mark() const': part-combine-iterator.cc:173: error: invalid use of '' on pointer to member 4.5 also ICEs the same way.
A brutal application of delta gives this short but non-sensical code: void f () ; struct A A :: * p ; int i = p ->* f ;
David Kastrup added the following comment to Launchpad bug report 984577: Just for the record: the source code triggering the error is invalid C++. It is just that an internal compiler error is a somewhat intimidating diagnostic. -- http://launchpad.net/bugs/984577
Created attachment 27390 [details] patch 1 ice.cc:2:15: error: pointer to member must be on the right side of '->*' int i = p ->* p ; ^ so the caret is on the wrong side of the operator.
If the patch otherwise works fine, I would encourage you to submit it anyway even if the caret isn't accurate: AFAICS, for all the errors emitted by that function the caret is at the end of the expression and fixing that may be conceptually simple but I don't think boils down to 10 or 20 lines, it seems a separate issue really.
Sorry, I think your message is not easily understandable. I think you are trying to say that "the right hand side must be a pointer-to-member", but this is not actually what your proposed message says. I like more clang's message: /tmp/webcompile/_28618_0.cc:4:11: error: right hand operand to ->* has non pointer-to-member type 'void ()' int i = p ->* f ; ^ ~ I am not saying that you need to print the type or fix the location (it would be nice but I understand it is quite extra work, and could be done later). But the text could say: "type of right-side operand of %<->*%> is not pointer-to-member", or "right-side operand of %<->*%> has non pointer-to-member type" or "right-side operand of %<->*%> must have pointer-to-member type".
As long as we avoid the ICE and the message is fine I'm happy. Then I'll take care of the column number asap.
Note: this is very old, I barely remember it. (In reply to comment #6) > Sorry, I think your message is not easily understandable. I think you are > trying to say that "the right hand side must be a pointer-to-member", No, I think I am saying: hello, this is the left hand side of a ->* operator, and you are feeding me a pointer to member, which obviously should be on the right hand side. > I like more clang's message: > > /tmp/webcompile/_28618_0.cc:4:11: error: right hand operand to ->* has non > pointer-to-member type 'void ()' > int i = p ->* f ; > ^ ~ The testcase in the patch has p ->* p, and clang says: test.cc:2:11: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct A::*' int i = p ->* p ; // { dg-error "" } ^~~ .* (not sure what that .* is doing there) > I am not saying that you need to print the type or fix the location (it would > be nice but I understand it is quite extra work, and could be done later). But > the text could say: "type of right-side operand of %<->*%> is not > pointer-to-member", or "right-side operand of %<->*%> has non pointer-to-member > type" or "right-side operand of %<->*%> must have pointer-to-member type". IIRC (and I could be wrong), this test is really about the lhs. Which doesn't mean that the error message is good...
(In reply to comment #8) > Note: this is very old, I barely remember it. > > (In reply to comment #6) > > Sorry, I think your message is not easily understandable. I think you are > > trying to say that "the right hand side must be a pointer-to-member", > > No, I think I am saying: hello, this is the left hand side of a ->* operator, > and you are feeding me a pointer to member, which obviously should be on the > right hand side. Ah! I was looking at the testcase here and I got confused. > test.cc:2:11: error: left hand operand to ->* must be a pointer to class > compatible with the right hand operand, but is 'struct A::*' > int i = p ->* p ; // { dg-error "" } > ^~~ > .* > > (not sure what that .* is doing there) Me neither, but clang's text is clearer in my humble opinion. I will be happy with the text changed to "left-side operand of %<->*%> must a pointer to class compatible with the right-side operand", and everything the same as your current patch. Please submit that!
Author: glisse Date: Fri Oct 12 14:14:37 2012 New Revision: 192401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192401 Log: 2012-10-12 Marc Glisse <marc.glisse@inria.fr> PR c++/53055 gcc/c-family/ * c-common.h (enum ref_operator) [RO_ARROW_STAR]: New. gcc/cp/ * call.c (build_new_op_1): Pass RO_ARROW_STAR to cp_build_indirect_ref. * typeck.c (cp_build_indirect_ref): Handle RO_ARROW_STAR. gcc/testsuite/ * g++.dg/pr53055.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr53055.C (with props) Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog Propchange: trunk/gcc/testsuite/g++.dg/pr53055.C ('svn:eol-style' added) Propchange: trunk/gcc/testsuite/g++.dg/pr53055.C ('svn:keywords' added)
(In reply to comment #7) > Then I'll take care of the column number asap. Ok, your turn ;-) (In reply to comment #9) > I will be happy > with the text changed to "left-side operand of %<->*%> must a pointer to class > compatible with the right-side operand", I went with: "left hand operand of ->* must be a pointer to class, but is a pointer to member of type ...", the bit about the RHS didn't seem relevant to this particular error. But you still have a chance to convince Paolo for the follow-up patch...
Great. This is fixed anyway.