From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80088-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6665 invoked by alias); 30 Jul 2003 12:23:38 -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 6642 invoked from network); 30 Jul 2003 12:23:26 -0000
Received: from unknown (HELO mailout04.sul.t-online.com) (194.25.134.18)
  by sources.redhat.com with SMTP; 30 Jul 2003 12:23:26 -0000
Received: from fwd05.aul.t-online.de 
	by mailout04.sul.t-online.com with smtp 
	id 19hpym-0001YN-03; Wed, 30 Jul 2003 14:22:52 +0200
Received: from kolme (TtiXLvZS8eitoJcDsWOS6f7TazsznN2ehtu8Z7tiF-RvtSJVlEzGo1@[80.138.148.130]) by fmrl05.sul.t-online.com
	with esmtp id 19hpyZ-12fW7M0; Wed, 30 Jul 2003 14:22:39 +0200
Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy)
	by kolme with esmtp (Exim 3.35 #1 (Debian))
	id 19hpyU-0000UN-00; Wed, 30 Jul 2003 14:22:34 +0200
Received: from richard (helo=localhost)
	by goofy with local-esmtp (Exim 3.36 #1 (Debian))
	id 19hpyW-0000Fu-00; Wed, 30 Jul 2003 14:22:36 +0200
Date: Wed, 30 Jul 2003 13:01:00 -0000
From: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, 
     <Richard.Earnshaw@arm.com>, Alexandre Oliva <aoliva@redhat.com>, 
     <gcc@gcc.gnu.org>
Subject: Re: std::pow implementation
In-Reply-To: <m3k7a08bf4.fsf@uniton.integrable-solutions.net>
Message-ID: <Pine.LNX.4.44.0307301416340.561-100000@goofy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Seen: false
X-ID: TtiXLvZS8eitoJcDsWOS6f7TazsznN2ehtu8Z7tiF-RvtSJVlEzGo1@t-dialin.net
X-SW-Source: 2003-07/txt/msg02138.txt.bz2

On 30 Jul 2003, Gabriel Dos Reis wrote:

> Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
>
> | Of course being able to hint the compiler some more can be useful to
> | overcome weakness in the compilers inlining decision implementation as
> | that never will be perfect.
>
> It takes first abandoning the idea that the compiler always knows
> better than the programmer and the programmer's use of "inline" is
> most of the time nonsensical.  The programmer does provide hint.  The
> compiler choses not to listen.

Well, the point is you question that inline should be a hint, but take it
as the same as __attribute__((always_inline)) is defined. The compiler is
free to ignore hints if it thinks the hint is against the task it is
performing (take f.i. a inline declared modestly sized function when
compiling with -Os).

I'd argue for the inline keyword makeing the compiler think twice before
not inlining a function and -finline-functions on by default (if inline is
a hint to inline, why should no inline force the compiler not to inline?).

Richard.