From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26664 invoked by alias); 17 Dec 2002 08:44:13 -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 26644 invoked from network); 17 Dec 2002 08:44:11 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by 209.249.29.67 with SMTP; 17 Dec 2002 08:44:11 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id gBH8b5tv006117; Tue, 17 Dec 2002 09:37:05 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id gBH8b41Z006116; Tue, 17 Dec 2002 09:37:04 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: David Edelsohn Cc: Zack Weinberg , Jan Hubicka , gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: basic-improvements merge status References: <200212162212.RAA27306@makai.watson.ibm.com> From: Gabriel Dos Reis In-Reply-To: <200212162212.RAA27306@makai.watson.ibm.com> Organization: Integrable Solutions Date: Tue, 17 Dec 2002 00:47:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg01002.txt.bz2 David Edelsohn writes: | >>>>> Zack Weinberg writes: | | Zack> David Edelsohn writes: | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize" | >> | >> (float) sin(x) | >> | >> as | >> | >> sinf(x)? | | Zack> I remember such an optimization being implemented but I can't find the | Zack> change log entry for it. My recollection is that it was Jan Hubicka | Zack> who coded it. Jan? | | Yes, it appears to be due to the builtins.def changes by Jan which | assumes that all of those functions natively are available on every | target. One cannot make that assumption. Testing for the existence of | those functions on the target is not easy. I think this is a case where GCC's logic in apply transformations just breaks down. | In most cases, the transformation will result in a linker error on | systems which do not provide the function, but libstdc++-v3 graciously | provides the symbols, creating a recursion in those definitions. I don't think libstdc++-v3 is at fault here. I think it is the middle-end. That is, if as a programmer, I do know that the target is lacking sinf() and consciously I did write "(float) sin(x)", then I find it a diservice that GCC calls a sinf(). Really. I see values for the mentioned transformation. But bindly applying it is a -not- a service. -- Gaby