From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30227 invoked by alias); 3 Mar 2004 18:12:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30211 invoked from network); 3 Mar 2004 18:12:45 -0000 Received: from unknown (HELO boden.synopsys.com) (198.182.44.79) by sources.redhat.com with SMTP; 3 Mar 2004 18:12:45 -0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by boden.synopsys.com (Postfix) with ESMTP id E7FDADD00; Wed, 3 Mar 2004 10:12:41 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA04341; Wed, 3 Mar 2004 10:12:44 -0800 (PST) Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id i23ICTl09786; Wed, 3 Mar 2004 10:12:29 -0800 X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f Date: Wed, 03 Mar 2004 18:12:00 -0000 From: Joe Buck To: Gabriel Dos Reis Cc: Alexandre Oliva , Daniel Berlin , Kevin Atkinson , Mark Mielke , gcc@gcc.gnu.org, Jeff Sturm , Nathan Sidwell Subject: Re: RFC: New C++ Attribute: final Message-ID: <20040303101229.A8644@synopsys.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gdr@integrable-solutions.net on Wed, Mar 03, 2004 at 06:24:37PM +0100 X-SW-Source: 2004-03/txt/msg00236.txt.bz2 On Wed, Mar 03, 2004 at 06:24:37PM +0100, Gabriel Dos Reis wrote: > More to the point, the case I just pointed out *is* an instance where > the function has final semantics and the compiler knows that. > > (1) In my case, it is known after the class foobar definition > that foobar::fun is final. The compiler does not optimize the > vcall. I don't think a keyword is needed for that. > Usage of local classes like that are common. > > (2) in the testcase I gave to Joe, I'm pointing out that GCC still > don't quite understand pointer-to-member-function and optimize > accordingly. And this is a case where all information are > available, in the specific context the call is made. > > I'm saying that given both (1) and (2), it looks like we would be > trumping people, for they are already saying "final" and we don't optimize. Agreed; the first thing we need to do is get the compiler to do a better job generating good code for ISO C++. > Those two cases do not cover all the semantics that a putative "final" > may have; but if we optimize those cases (which are quite common, > probably more common than the other corner cases) then we may be more > credible in saying that a keyword is needed to do a better job. I am interested in "final" not just to do a better job of optimization, but also for improved safety; there are many codes that implicitly assume "final" for correct operation (some gurus believe such codes are "broken" but any GNU/Linux distro is full of such "broken" code). Just the same, Gaby is right; we need to do a better job of avoiding virtual calls in cases where the compiler already can determine that a specific function must be called.