From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19010 invoked by alias); 30 Jul 2003 14:14:15 -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 18981 invoked from network); 30 Jul 2003 14:14:14 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Jul 2003 14:14:14 -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 h6UEDmSu021840; Wed, 30 Jul 2003 16:13:48 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UEDldH021839; Wed, 30 Jul 2003 16:13:47 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Richard.Earnshaw@arm.com Cc: Karel Gardas , Alexandre Oliva , Richard Guenther , gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <200307301401.h6UE1oN19727@pc960.cambridge.arm.com> From: Gabriel Dos Reis In-Reply-To: <200307301401.h6UE1oN19727@pc960.cambridge.arm.com> Organization: Integrable Solutions Date: Wed, 30 Jul 2003 14:26:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02177.txt.bz2 Richard Earnshaw writes: | > | > | With Gaby's suggested interpretation, the compiler has *no* choice; it | > | > | must obey the inlining constraint because the programmer always knows | > | > | better... Even when prepared to admit that he doesn't. | > | > | > | > That assertion is wrong. | > | | > | Which bit of it? It's what I understand you to be suggesting. | > | > As I've repeatedly said, there are pathological cases where the | > compiler simply cannot inline. Secondly, I'm saying that the | > compiler does not always know better than the programmer. And in fact, | > the programmer most of the time declares "inline" on purpose. | > | > Transmuting the meaning of "inline" is creating more fear, uncertainty | > and doubt than we needed. | | Suggesting that a programmer must only use inline when they are convinced | that better code will always result (ie that using inline when it may only | sometimes produce better code is "dangerous") sounds even more like | spreading FUD to me. You're going to get people saying "Never use inline, | it can make your code worse". Please, I didn't suggest that. -- Gaby