From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28840 invoked by alias); 29 Jul 2003 12:53:37 -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 28772 invoked from network); 29 Jul 2003 12:53:36 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 29 Jul 2003 12:53:36 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6TCrOSu013969; Tue, 29 Jul 2003 14:53:24 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6TCrNJZ013968; Tue, 29 Jul 2003 14:53:23 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Richard Guenther Cc: Steven Bosscher , Subject: Re: std::pow implementation References: From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Tue, 29 Jul 2003 13:14:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg01979.txt.bz2 Richard Guenther writes: | > | Now cut away all the redundant labels and other cruft, and you end up | > | with: | > | > In short, you have demonstrated that if "inline" is given its obvious | > meaning, the compiler can do a better job. That is what I claimed in | > the first place. | | Note that Steven checked with -O3, so wether inline is specified here or | not should be meaningless(?). I'm not sure that should be meaningless. At -O3, GCC does not inline imaginable functions. -- Gaby