From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-92649-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28930 invoked by alias); 15 Mar 2004 18:13:17 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 28901 invoked from network); 15 Mar 2004 18:13:16 -0000
Received: from unknown (HELO kiruna.synopsys.com) (198.182.44.80)
  by sources.redhat.com with SMTP; 15 Mar 2004 18:13:16 -0000
Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23])
	by kiruna.synopsys.com (Postfix) with ESMTP
	id BB8D2F401; Mon, 15 Mar 2004 10:13:08 -0800 (PST)
Received: from piper.synopsys.com (localhost [127.0.0.1])
	by crone.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA25042;
	Mon, 15 Mar 2004 10:13:13 -0800 (PST)
Received: (from jbuck@localhost)
	by piper.synopsys.com (8.11.6/8.11.6) id i2FIDDT04553;
	Mon, 15 Mar 2004 10:13:13 -0800
X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f
Date: Mon, 15 Mar 2004 18:13:00 -0000
From: Joe Buck <Joe.Buck@synopsys.COM>
To: Jakub Jelinek <jakub@redhat.com>
Cc: James Morrison <ja2morri@csclub.uwaterloo.ca>,
	Roger Sayle <roger@eyesopen.com>,
	Scott Robert Ladd <coyote@coyotegulch.com>, gcc@gcc.gnu.org
Subject: Re: GCC viciously beaten by ICC in trig test!
Message-ID: <20040315101313.A4286@synopsys.com>
References: <Pine.LNX.4.44.0403141713460.12909-100000@www.eyesopen.com> <kfhllm21yj0.fsf@perpugilliam.csclub.uwaterloo.ca> <20040315061104.GR3822@sunsite.ms.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20040315061104.GR3822@sunsite.ms.mff.cuni.cz>; from jakub@redhat.com on Mon, Mar 15, 2004 at 07:11:04AM +0100
X-SW-Source: 2004-03/txt/msg00730.txt.bz2

On Mon, Mar 15, 2004 at 07:11:04AM +0100, Jakub Jelinek wrote:
> Well, the inlines shouldn't be removed, but guarded with
> # if !__GNUC_PREREQ (MAJOR,MINOR)
> ...
> # endif
> where MAJOR, MINOR is the first __GNUC__ and __GNUC_MINOR__ of GCC which
> can handle all cases the same or better than the glibc inline.

Is the proper requirement "all cases"?  What if the glibc inline is
sometimes better, but sometimes far worse?

Also, that method means that the glibc people have to maintain crufty
inline assembler forever for the sake of producing slightly better code
on some ancient GCC version.  Speed is important, but so is
maintainability, so this might be worth doing only if the speed gain is
substantial.