This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8826: "a >> b" differs from "a.operator>>(b)" in that virtual function calls are not avoided
- From: bangerth at dealii dot org
- To: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, niemayer at isg dot de, nobody at gcc dot gnu dot org
- Date: 5 Dec 2002 19:34:08 -0000
- Subject: Re: c++/8826: "a >> b" differs from "a.operator>>(b)" in that virtual function calls are not avoided
- Reply-to: bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, niemayer at isg dot de, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: "a >> b" differs from "a.operator>>(b)" in that virtual function calls are not avoided
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Thu Dec 5 11:34:07 2002
State-Changed-Why:
Confirmed. This is a very annoying bug, which would be nice
if someone looked at it soon, since there should really
be no reason why the two calls are treated differently; this
raises the question whether there are more _correctness_
problems lurking somewhere. Note that the code uses
a.operator>>(y)
not
a.A::operator>>(y)
!
In any case, removing the asm labels that only are there to
help reading the asm code, the second function where the
virtual function call is elided is compiled into
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl 8(%ebp), %eax
movl %ebp, %esp
popl %ebp
incl %eax
ret
which is a far cry from optimal. Essentially, the computation
of the function's value has been scheduled after the
epilog, but then pro- and epilog could be merged and
deleted. This is not done.
Things are a little better with -fomit-frame-pointer:
subl $28, %esp
movl 32(%esp), %eax
addl $28, %esp
incl %eax
ret
but still not optimal.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8826