This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Implicit generation of runtime calls
- From: Jan Hubicka <jh at suse dot cz>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org,David Edelsohn <dje at watson dot ibm dot com>,Zack Weinberg <zack at codesourcery dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,"libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>,Richard Henderson <rth at redhat dot com>
- Date: Tue, 17 Dec 2002 23:18:17 +0100
- Subject: Re: Implicit generation of runtime calls
- References: <20021217084635.GQ3138@kam.mff.cuni.cz> <50420000.1040142058@warlock.codesourcery.com> <20021217221411.GF7486@kam.mff.cuni.cz>
>
> 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