From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19807 invoked by alias); 30 Jul 2003 16:49:14 -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 19799 invoked from network); 30 Jul 2003 16:49:12 -0000 Received: from unknown (HELO ams006.ftl.affinity.com) (216.219.253.199) by sources.redhat.com with SMTP; 30 Jul 2003 16:49:12 -0000 Received: from coyotegulch.com ([68.200.44.160]) by ams.ftl.affinity.com with ESMTP id <217294-22773>; Wed, 30 Jul 2003 12:48:29 -0400 Message-ID: <3F27F6D9.30809@coyotegulch.com> Date: Wed, 30 Jul 2003 17:02: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: Richard.Earnshaw@arm.com CC: Gabriel Dos Reis , Alexandre Oliva , Richard Guenther , gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <200307301629.h6UGTBk21027@pc960.cambridge.arm.com> In-Reply-To: <200307301629.h6UGTBk21027@pc960.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg02224.txt.bz2 Richard Earnshaw wrote: >> When I say "inline", I mean inline, regardless of other opinions >> (including those of the compiler). > > Really? And when you say "register" do you really mean that? If so, > then I'm sorry, but you are in for a big disappointment when using > gcc -- it completely ignores the register keyword when optimizing and > has done since ~forever. Yes -- but as others have pointed out, automatic register allocation is a well-defined discipline that has proven itself. I have seen much evidence (including the original basis for this thread) that automatic inliners are still primitive. One root of this dicussion is differences in definitions (and expectations) between C, Ada, and C++. > I've already given examples of when the compiler can make use of > context to give better inlining than can be determined statically. > Your "arrogant" assertion that inline must always and unconditionally > mean inline impliess that programmers can never take advantage of > those cases. No; I imply that a C++ compiler should do as it's told, and explain itself when it makes a contrary decision. I don't doubt that the compiler can find optimizations that are beyond my analysis; I also know compilers can (and do) generate bad code. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing