From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8606 invoked by alias); 30 Jul 2003 14:08:05 -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 8548 invoked from network); 30 Jul 2003 14:08:04 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 30 Jul 2003 14:08:04 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 7C211F2DED; Wed, 30 Jul 2003 10:08:04 -0400 (EDT) To: gdr@integrable-solutions.net, rguenth@tat.physik.uni-tuebingen.de Subject: Re: std::pow implementation Cc: Richard.Earnshaw@arm.com, aoliva@redhat.com, gcc@gcc.gnu.org, kgardas@objectsecurity.com Message-Id: <20030730140804.7C211F2DED@nile.gnat.com> Date: Wed, 30 Jul 2003 14:18:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-07/txt/msg02172.txt.bz2 > The only sane possible semantics I see are: > > 1. inline declared functions are inlined always if technically possible > 2. the inline keyword has no effect > 3. inline is handled in an implementation defined manner (as stated in the > standard), maybe by adjusting the set of functions considered for inlining, > as gcc does. None of these three semantics make sense to me. The only one that makes sense is the one I gave before. Speed up calls to this function, by doing optimizations (most obviously by inlining the call) that speed up execution, even if it results in extra space for generated code. (the comment here is suggestive, not normative, in standards terms, but we know perfectly well what it means as implementors).