From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29759 invoked by alias); 17 Dec 2002 08:51:45 -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 29734 invoked from network); 17 Dec 2002 08:51:43 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by 209.249.29.67 with SMTP; 17 Dec 2002 08:51:43 -0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id E031C4E154; Tue, 17 Dec 2002 09:50:43 +0100 (CET) Date: Tue, 17 Dec 2002 00:54:00 -0000 From: Jan Hubicka To: Gabriel Dos Reis Cc: David Edelsohn , Zack Weinberg , Jan Hubicka , gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: basic-improvements merge status Message-ID: <20021217085043.GR3138@kam.mff.cuni.cz> References: <200212162212.RAA27306@makai.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2002-12/txt/msg01006.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. Yes, I see that. But it is really not different from reusing memset() call for totally different purpose. You function is not valid C so it should use -fdisable-builtins. > > I see values for the mentioned transformation. But bindly applying it > is a -not- a service. In what conditions do you think we should apply that? Honza > > -- Gaby