This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/10858: failure with calling a method inside sizeof: sorry, unimplemented: `method_call_expr' not supported by dump_expr
- From: bangerth at dealii dot org
- To: dominique dot devriese at student dot kuleuven dot ac dot be, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Date: 20 May 2003 01:02:32 -0000
- Subject: Re: c++/10858: failure with calling a method inside sizeof: sorry, unimplemented: `method_call_expr' not supported by dump_expr
- Reply-to: bangerth at dealii dot org, dominique dot devriese at student dot kuleuven dot ac dot be, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Old Synopsis: bogus compiler failure while compiling Boost.Python
New Synopsis: failure with calling a method inside sizeof: sorry, unimplemented: `method_call_expr' not supported by dump_expr
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Tue May 20 01:02:32 2003
State-Changed-Why:
Confirmed. Here's a much smaller snippet:
----------------------
template <int> struct P {};
void bar ();
template <class T> struct X {
static int foo(void (*)());
P<sizeof(foo(&bar))> p;
};
template class X<int>;
--------------------------
With 3.3, we presently get:
g/x> /home/bangerth/bin/gcc-3.3-pre/bin/g++ -c x.cc
x.cc:7: sorry, unimplemented: `method_call_expr' not supported by dump_expr
x.cc:7: sorry, unimplemented: `method_call_expr' not supported by dump_expr
With 3.4, this code doesn't go through the parser (which is
reported elsewhere), so it's hard to tell whether the
problem is fixed there. Here's what present mainline
gives us:
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/g++ -c x.cc
x.cc: In instantiation of `X<int>':
x.cc:10: instantiated from here
x.cc:7: error: invalid use of undefined type `struct X<int>'
x.cc:5: error: declaration of `struct X<int>'
Working around the problem in 3.4 by using X::foo makes
the problem go away in 3.3 and 3.4. I tend to think, though,
that this is indeed valid code and that it should be accepted
in any case.
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10858