From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-25762-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 13217 invoked by alias); 5 Dec 2002 19:34:09 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 13198 invoked by uid 61); 5 Dec 2002 19:34:08 -0000
Date: Thu, 05 Dec 2002 11:34:00 -0000
Message-ID: <20021205193408.13197.qmail@sources.redhat.com>
To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, niemayer@isg.de,
  nobody@gcc.gnu.org
From: bangerth@dealii.org
Reply-To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  niemayer@isg.de, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/8826: "a >> b" differs from "a.operator>>(b)" in that virtual function calls are not avoided
X-SW-Source: 2002-12/txt/msg00291.txt.bz2
List-Id: <gcc-prs.sourceware.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