From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19747 invoked by alias); 17 Dec 2002 22:18:34 -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 19691 invoked from network); 17 Dec 2002 22:18:29 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by 209.249.29.67 with SMTP; 17 Dec 2002 22:18:29 -0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 545434EBB5; Tue, 17 Dec 2002 23:18:17 +0100 (CET) Date: Tue, 17 Dec 2002 14:51:00 -0000 From: Jan Hubicka To: Jan Hubicka Cc: Mark Mitchell , gcc-patches@gcc.gnu.org, David Edelsohn , Zack Weinberg , "gcc@gcc.gnu.org" , "libstdc++@gcc.gnu.org" , Richard Henderson Subject: Re: Implicit generation of runtime calls Message-ID: <20021217221817.GG7486@kam.mff.cuni.cz> References: <20021217084635.GQ3138@kam.mff.cuni.cz> <50420000.1040142058@warlock.codesourcery.com> <20021217221411.GF7486@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021217221411.GF7486@kam.mff.cuni.cz> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-12/txt/msg01078.txt.bz2 > > Hi, > this patch adds the infrastructure to determine whether the function call can > be produced implicitly or not. I am doing that by new array of declarations > implicit_built_in_decls that has entry nonzero just for those builtins that are > safe. > In future we may want to modify the declarations so the builtin expansion can > behave differently for implicit calls as they do already for __builtin_XXX calls > and XXX calls. > > DEF_BUILTIN now allows to declare whehter the function is available and I've > categorized the functions according to C99 and C90 standards. > I also added the TARGET_C99_FUNCTIONS defined to 1 by default and function > to get the declaration in proper mode so conversions can be done easilly. > > Thats it. In the next step I would like to re-enable the transformation as > next step once this part is polished. I would also like to turn > TARGET_MEM_FUNCTIONS into this scheme. I intended to do this in one step but > the patch is getting bigger than I would like it to be already. > > I will happily add -fno-c99-builtins switch to configure and manage it to > control TARGET_C99_FUNCTIONS if someone will make me believe that this is good. > I think this is static knowledge about the particular port and the problems > with autoconfiguration being different in different contexts, so it will > bring us problems in reproducing failures reported in cross envorinment > and so on. > > I also don't think it makes sense to allow controlling each function > individually. We already support about 10-20 such functions and the number of > them will increase. I don't think runtimes are crazy enought to commonly > support just arbitary subset of these, so this would just anoy. We can invent > 1-2 new categories (perhaps there can be category for runtimes deifning sinf > but not sinl or cabs if such exists) > > Bootstrapped/regtested mainline. I also tested that it disables/enables the transformation as needed :) In the followup I will add testcase to the testsuite so ports where default is wrong will get caught and re-enable the transformation Honza