From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15101 invoked by alias); 31 Jul 2003 13:12:47 -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 15094 invoked from network); 31 Jul 2003 13:12:46 -0000 Received: from unknown (HELO ams005.ftl.affinity.com) (216.219.253.199) by sources.redhat.com with SMTP; 31 Jul 2003 13:12:46 -0000 Received: from coyotegulch.com ([68.200.44.160]) by ams.ftl.affinity.com with ESMTP id <215472-11470>; Thu, 31 Jul 2003 09:11:57 -0400 Message-ID: <3F29159B.8060609@coyotegulch.com> Date: Thu, 31 Jul 2003 14:13:00 -0000 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: en MIME-Version: 1.0 To: Rob Taylor CC: "Gcc@Gcc. Gnu. Org" Subject: Re: std::pow implementation References: <041f01c3574f$f51e9180$b800a8c0@eventhorizon> In-Reply-To: <041f01c3574f$f51e9180$b800a8c0@eventhorizon> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg02309.txt.bz2 Rob Taylor wrote: > 2) every function has to be maybe-inlinable for good optimisation, but the > inline keyword gives good hinting and should be used. That's close to my position on the matter. 1) The compiler should be able to determine which functions it can effectively inline for a given circumstance. 2) The compiler should respect "inline" directives from the programmer, generating inline code when it is specified, unless doing so is technically impossible or blatantly inefficient. 3) If the compiler rejects an "inline" request, it should clearly state why it did so. After all, if the compiler is smart enough to second-guess me, it should also be able to explain itself. ;) Such an approach gives the compiler maximum flexibility while respecting the choices of the programmer. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing