From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10483 invoked by alias); 15 Mar 2004 02:41:00 -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 10467 invoked from network); 15 Mar 2004 02:40:59 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sources.redhat.com with SMTP; 15 Mar 2004 02:40:59 -0000 Received: from caip.rutgers.edu (localhost [127.0.0.1]) by caip.rutgers.edu (8.12.9/8.12.9) with ESMTP id i2F2ehvM029746; Sun, 14 Mar 2004 21:40:43 -0500 (EST) Received: (from ghazi@localhost) by caip.rutgers.edu (8.12.9/8.12.9/Submit) id i2F2egRD029745; Sun, 14 Mar 2004 21:40:42 -0500 (EST) Date: Mon, 15 Mar 2004 02:41:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200403150240.i2F2egRD029745@caip.rutgers.edu> To: roger@eyesopen.com Subject: Re: GCC viciously beaten by ICC in trig test! Cc: coyote@coyotegulch.com, gcc@gcc.gnu.org References: X-SW-Source: 2004-03/txt/msg00650.txt.bz2 > The issue is that glibc's headers provide inline implementations for > sin and cos, and thereby override all of GCC's internal builtin > processing. Once this is done, there's nothing tree-ssa, the > middle-end or the i386 can do to improve the code. If GCC is to have > a hope of using "sincos" or SSE2 specific instruction sequences, the > "best intentions" of glibc's headers (will) have to be neutralized > first. Perhaps fixincludes :> Or you can pass -D__NO_INLINE__ on the command line. I'm of the opinion that we should add that to GCC's specs for all glibc systems. We already do something analogous during bootstrap for GCC itself to disable all of the glibc string inlines. I don't see why the rest of the world has to suffer through them when these things belong in the compiler anyway. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu