I have a very simple piece of code that will produce the following error: -- test.C:5: internal compiler error: in output_constant, at varasm.c:4031 -- A simple code fragment to reproduce this bug is: -- struct foo { public: virtual int bar(int); }; void (foo::*__Virtual__foo__Var1)() = (void (foo::*)())(&foo::bar); -- I've observed this bug on both ppc and x86 platforms with various builds of the 4.1.x and 4.0.x trees. Note that 3.x _will_ compile this correctly. thanks Donour Sizemore
Created attachment 11736 [details] demo of reported behavior
I cannot figure out if this is undefined code or not but it should not at least ICE.
Subject: Re: ICE with pointer to member function initializer and cast to a different type pinskia at gcc dot gnu dot org wrote: > ------- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 02:03 ------- > I cannot figure out if this is undefined code or not but it should not at least > ICE. > > > That should be legal ISO c++. That type of constuct is used actually pretty common in specific types of applications (OS and embedded apps). thanks donour
(In reply to comment #3) > Subject: Re: ICE with pointer to member function initializer > and cast to a different type > That should be legal ISO c++. That type of constuct is used actually > pretty common in specific types of applications (OS and embedded apps). What I mean is that the type of the arguments and return type don't match so if you use __Virtual__foo__Var1 without a cast back, the code would be undefined.
This code is not valid ISO C++; there is no conversion from function pointers (including pointers to member functions) from one type to another.
I don't know what I was thinking when I proclaimed this invalid code. It's clearly valid; the cast is a reinterpret_cast.
Subject: Re: [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type mmitchel at gcc dot gnu dot org wrote: > ------- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-03 07:36 ------- > I don't know what I was thinking when I proclaimed this invalid code. It's > clearly valid; the cast is a reinterpret_cast. > > Ok great. The issue is not really pressing with me anymore, as I've rewritten the offending code to alleviate the problem. Although I'm sure you want to get rid of all known ICE bugs. donour
Subject: Bug 28148 Author: mmitchel Date: Fri Aug 4 04:58:36 2006 New Revision: 115919 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115919 Log: PR c++/28148 * varasm.c (output_constant): Give the front end another chance to expand constants, after stripping NOPs. PR c++/28148 * g++.dg/init/ptrmem3.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/ptrmem3.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
Subject: Bug 28148 Author: mmitchel Date: Fri Aug 4 05:00:03 2006 New Revision: 115920 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115920 Log: PR c++/28148 * varasm.c (output_constant): Give the front end another chance to expand constants, after stripping NOPs. PR c++/28148 * g++.dg/init/ptrmem3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/ptrmem3.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/varasm.c
Fixed in 4.1.2.
Fixed in GCC-4.1.2.