From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80105-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6369 invoked by alias); 30 Jul 2003 13:40:16 -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 6346 invoked from network); 30 Jul 2003 13:40:11 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 30 Jul 2003 13:40:11 -0000
Received: by nile.gnat.com (Postfix, from userid 338)
	id 9BBA0F2DFE; Wed, 30 Jul 2003 09:40:11 -0400 (EDT)
To: aoliva@redhat.com, gdr@integrable-solutions.net
Subject: Re: std::pow implementation
Cc: gcc@gcc.gnu.org, rguenth@tat.physik.uni-tuebingen.de,
	s.bosscher@student.tudelft.nl
Message-Id: <20030730134011.9BBA0F2DFE@nile.gnat.com>
Date: Wed, 30 Jul 2003 13:52:00 -0000
From: dewar@gnat.com (Robert Dewar)
X-SW-Source: 2003-07/txt/msg02155.txt.bz2

> 
> Therefore, inline the way you describe it, is useful only for
> functions that are *always* profitable to inline.  Any function that
> might or might not be profitable to inline should not be declared
> inline, and the compiler would never inline it.

And of course this approach is impractical, since whether inlining helps
in a specific case is target dependent.