This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [RFC] Enable math functions linking with static library for LTO


I'm afraid I'm not clear on the semantics of builtin_with_linkage_p (as in 
the current checked-in version).  It says:

/* Return true if the builtin DECL is implemented in a standard library.
   Otherwise returns false which doesn't guarantee it is not (thus the list of
   handled builtins below may be incomplete).  */

But what does "is implemented in a standard library" mean?  Certainly 
plenty of GCC ports are for systems that e.g. don't have fmaf64 which is 
included in that switch statement, and calls to fmaf64 on such systems 
will result in an undefined reference unless it's on an architecture where 
GCC can expand that inline.

Specifically: does Tejas's roundeven patch (and likewise the fadd patch) 
need updating to add those functions to the switch statement in 
builtin_with_linkage_p?  What are the correct semantics for a built-in 
function with the following properties: it may not be in the system libc / 
libm on all systems, but GCC can't always expand it inline either, so it 
may result in an undefined reference on systems where it's not in system 
libc / libm?

If it's only meant to be for functions you *know* are in a standard 
library on the system used, I'd expect checks of the libc_has_function 
target hook.  If, however, it's meant to be for functions that might 
result in an undefined reference (where GCC expects there to be a library 
function to satisfy that reference, but some systems don't have that 
function), I'd expect it to be based on whether a library name was passed 
when add_builtin_function was called, if that's something you can 
determine by examining the DECL - and in that case I wouldn't expect 
there to be a long switch statement listing particular functions, because 
the relevant information is specified when the built-in functions are 
created in the first place.

-- 
Joseph S. Myers
joseph@codesourcery.com


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