From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80123-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8866 invoked by alias); 30 Jul 2003 14:08:18 -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 8538 invoked from network); 30 Jul 2003 14:08:04 -0000
Received: from unknown (HELO mailout03.sul.t-online.com) (194.25.134.81)
  by sources.redhat.com with SMTP; 30 Jul 2003 14:08:04 -0000
Received: from fwd00.aul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 19hrcY-0003f8-0A; Wed, 30 Jul 2003 16:08:02 +0200
Received: from kolme (rIZLv2ZQge3ZW91jrX9FXjP-8ZZ8jdfpjRvRRK3NRYCr3bhvdB4H8i@[80.138.148.130]) by fmrl00.sul.t-online.com
	with esmtp id 19hrcJ-0DefaK0; Wed, 30 Jul 2003 16:07:47 +0200
Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy)
	by kolme with esmtp (Exim 3.35 #1 (Debian))
	id 19hrcG-0000Wd-00; Wed, 30 Jul 2003 16:07:44 +0200
Received: from richard (helo=localhost)
	by goofy with local-esmtp (Exim 3.36 #1 (Debian))
	id 19hrcH-0000Ou-00; Wed, 30 Jul 2003 16:07:45 +0200
Date: Wed, 30 Jul 2003 14:19:00 -0000
From: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
To: gcc@gcc.gnu.org
cc: Gabriel Dos Reis <gdr@integrable-solutions.net>, 
     <Richard.Earnshaw@arm.com>, Karel Gardas <kgardas@objectsecurity.com>, 
    Alexandre Oliva <aoliva@redhat.com>
Subject: Re: std::pow implementation
In-Reply-To: <Pine.LNX.4.44.0307301553090.561-100000@goofy>
Message-ID: <Pine.LNX.4.44.0307301606250.561-100000@goofy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Seen: false
X-ID: rIZLv2ZQge3ZW91jrX9FXjP-8ZZ8jdfpjRvRRK3NRYCr3bhvdB4H8i@t-dialin.net
X-SW-Source: 2003-07/txt/msg02173.txt.bz2

On Wed, 30 Jul 2003, Richard Guenther wrote:

> The only sane possible semantics I see are:
>
> 1. inline declared functions are inlined always if technically possible
> 2. the inline keyword has no effect
> 3. inline is handled in an implementation defined manner (as stated in the
>    standard), maybe by adjusting the set of functions considered for inlining,
>    as gcc does.
>
> I argue we cannot go away from #3 without portability problems (to other
> compilers and architectures).

Of course I see gcc's usage of #3 can be improved by, f.i. giving
inlining limits a boost for functions declared inline.

Richard.