internal compiler error: in cp_build_indirect_ref, at cp/typeck.c:2786

Bug #984577 reported by David Kastrup on 2012-04-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc
Fix Released
Medium
gcc-4.6 (Ubuntu)
Medium
Unassigned

Bug Description

DEPENDENCIES_OUTPUT="./out/part-combine-iterator.dep ./out/part-combine-iterator.o" g++ -c -Woverloaded-virtual -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -g -fwrapv -g -fstack-protector --param=ssp-buffer-size=4 -DHAVE_CONFIG_H -I./include -I./out -I../flower/include -I../flower/./out -I../flower/include -g -pipe -fno-optimize-sibling-calls -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -Wno-pmf-conversions -W -Wall -Wconversion -o out/part-combine-iterator.o part-combine-iterator.cc
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:2786
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cc6YKx3d.out file, please attach this to your bugreport.

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: g++-4.6 4.6.3-1ubuntu5
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic i686
ApportVersion: 2.0.1-0ubuntu4
Architecture: i386
Date: Wed Apr 18 07:38:40 2012
ExecutablePath: /usr/lib/gcc/i686-linux-gnu/4.6/cc1plus
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111011)
SourcePackage: gcc-4.6
UpgradeStatus: Upgraded to precise on 2012-04-11 (6 days ago)

David Kastrup (dak) wrote :
In , Doko-v (doko-v) wrote :

Created attachment 27203
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.

Matthias Klose (doko) wrote :

seen with 4.6, 4.7 and trunk

Changed in gcc-4.6 (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
In , Rguenth (rguenth) wrote :

Created attachment 27204
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.

Changed in gcc:
importance: Unknown → Medium
status: Unknown → New

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.

A brutal application of delta gives this short but non-sensical code:

void f () ;
struct A A :: * p ;
int i = p ->* f ;

Changed in gcc:
status: New → Confirmed

Created attachment 27390
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 <email address hidden>

 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.

Changed in gcc:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.