From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27277 invoked by alias); 16 Dec 2002 23:05:48 -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 27259 invoked from network); 16 Dec 2002 23:05:46 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by 209.249.29.67 with SMTP; 16 Dec 2002 23:05:46 -0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 4E9094EC12; Tue, 17 Dec 2002 00:04:48 +0100 (CET) Date: Mon, 16 Dec 2002 15:10:00 -0000 From: Jan Hubicka To: Neil Booth Cc: Jan Hubicka , David Edelsohn , Zack Weinberg , gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: basic-improvements merge status Message-ID: <20021216230448.GJ3138@kam.mff.cuni.cz> References: <87bs3l3ab5.fsf@egil.codesourcery.com> <200212162212.RAA27306@makai.watson.ibm.com> <20021216221828.GB3138@kam.mff.cuni.cz> <20021216222324.GA511@daikokuya.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021216222324.GA511@daikokuya.co.uk> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-12/txt/msg00961.txt.bz2 > Jan Hubicka wrote:- > > > > > > > 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 noticed that already and there is patch waiting for that. So hope it > > will get reviewed soon. > > I am not quite sure how to deal with this (whether we can autoconfigure > > on whether runtime does have them or not). At the moment I do the > > transformation only when -std=c99 or gnu99 is specified when the > > transformation is valid as the standard requires these functions. > > But those switches are statements about what features the compiler > should accept, and compiler semantics. They say nothing about the > library conformance of the target to C99, IMO. The patch is more about adding infrastructure to specify about builtin whether compiler can produce it implicitly than about the actual decision. I expected the thread open when I sent the patch, so perhaps it happent now. I see that doing this transformation is different from the other decision we make based on language switch and would be happy about the better alternative. It is clear that in C99 environment this transformation is valid. To my surprise it is important one. In C90 compliant program there is no other way to write such code and even after that people are still using it, so the tranformation matches about houndred times in SPEC2000 and even more times in real world 3d programs, like Mesa, Crystal Space and similar often in internal loops. I would definitly like to see this enabled by default on Linux, that is not the case if we conditionalize it by C99. Honza > > Neil.