This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implicit generation of runtime calls


> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]