From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29244 invoked by alias); 4 Aug 2003 18:17:19 -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 29230 invoked from network); 4 Aug 2003 18:17:17 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 4 Aug 2003 18:17:17 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 7B56CF2A5F; Mon, 4 Aug 2003 14:17:17 -0400 (EDT) To: gdr@integrable-solutions.net, jbuck@synopsys.com Subject: Re: std::pow implementation Cc: aoliva@redhat.com, bernds@redhat.com, dewar@gnat.com, gcc@gcc.gnu.org, rguenth@tat.physik.uni-tuebingen.de, s.bosscher@student.tudelft.nl Message-Id: <20030804181717.7B56CF2A5F@nile.gnat.com> Date: Mon, 04 Aug 2003 18:21:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-08/txt/msg00189.txt.bz2 > I won't insist on the "as-if" rule: the longstanding promise in the GCC > manual that "an inlined function is as fast as a macro" will do for me > as a spec. If you can achieve that without actually doing the inlining, > go for it. That's a problematic spec, it is not at all clear that you cam make this guarantee. In our experience, you often get some junk from the inlining process in gcc that is eliminated if you do macro expansion. In fact we recently implemented front end inlining in GNAT (the -gnatN switch) which gives something closer to C macro behavior, and we often find that we get better code.