From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-79950-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8333 invoked by alias); 29 Jul 2003 14:27:44 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 8306 invoked from network); 29 Jul 2003 14:27:43 -0000
Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 29 Jul 2003 14:27:43 -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 h6TERVSu014549;
	Tue, 29 Jul 2003 16:27:31 +0200
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6TERUxk014548;
	Tue, 29 Jul 2003 16:27:30 +0200
X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>, gcc@gcc.gnu.org
Subject: Re: std::pow implementation
References: <Pine.LNX.4.44.0307291353040.14031-100000@bellatrix.tat.physik.uni-tuebingen.de>
	<m3he55tu7y.fsf@uniton.integrable-solutions.net>
	<1059481647.3651.120.camel@steven.lr-s.tudelft.nl>
	<m3wue1se52.fsf@uniton.integrable-solutions.net>
	<1059483328.3651.144.camel@steven.lr-s.tudelft.nl>
	<m34r15scu3.fsf@uniton.integrable-solutions.net>
	<1059487859.3650.208.camel@steven.lr-s.tudelft.nl>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <1059487859.3650.208.camel@steven.lr-s.tudelft.nl>
Organization: Integrable Solutions
Date: Tue, 29 Jul 2003 14:51:00 -0000
Message-ID: <m3ptjto1bh.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-07/txt/msg02000.txt.bz2

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

| > |  What I've shown is that the compiler can take a hint.
| > 
| > No, you've shown that on a branch development, the compiler appears to
| > give "inline" its obvious meaning.
| 
| BS.  The trunk does exactly the same thing, it's still the same tree
| inliner.  You should have tried it before you made this absurd
| statement.

The point you seem to be missing is that whether a function is inlined
depends on the context of use -- not just on its intrinsinc complexity.
That is what is absurd.  Not the mere statement of that fact.

-- Gaby