From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9781 invoked by alias); 30 Jul 2003 13:46: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 9773 invoked from network); 30 Jul 2003 13:46:14 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 30 Jul 2003 13:46:14 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 2C021F2DFE; Wed, 30 Jul 2003 09:46:14 -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: <20030730134614.2C021F2DFE@nile.gnat.com> Date: Wed, 30 Jul 2003 13:56:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-07/txt/msg02157.txt.bz2 > Defining a function inline is not a careless action. If inlining > isn't profitable, the programmer will profile et remove the inline > definition. You don't know better than the programmer. This is often incorrect, because often code is written to be portable, and the decision on what is profitable to inline is target dependent. Furthermore deciding whether something is profitable to inline on a given target requires detailed knowledge of the target architecture, knowledge that very few programmers have these days.