This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Enable math functions linking with static library for LTO
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Xiong Hu Luo <luoxhu at linux dot vnet dot ibm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <segher at kernel dot crashing dot org>, <wschmidt at linux dot ibm dot com>, <luoxhu at linux dot ibm dot com>, <richard dot guenther at gmail dot com>, <mjambor at suse dot cz>, <tejasjoshi9673 at gmail dot com>
- Date: Wed, 21 Aug 2019 19:55:57 +0000
- Subject: Re: [RFC] Enable math functions linking with static library for LTO
- Ironport-sdr: B3ys9Cw97QBqL4j9J0puB6Kiu7rwBCw+uE00djx9wVrvJcraHjnG/glA9VXLmkA/X/PSulj3gv ueMYTCR94QwnVKaPFnfbDqazSfpcknVCl62aW1WZy1S0pU9YK7xwfiyv/v2YY7k7lzTa2OrR58 3Fb7w1R2YbqWd7ZmwSg5kl5xzIr8QW9F5C48HjGT5b4HwPvWmgiTWL/5m+vHoaNjJGUZ6umsu7 wbGhuhXqtdsWi39B51uudLCV/yizfk/nVUl+qPms6OGmyFs9zlPCCUvVq1WJXyeJ0gdwKUqzyi szo=
- Ironport-sdr: fB/aYnHWof2DPGEx63q8McnqZ870Er/UenHPkRKgHCkMyElq97HYZfdfkm8xr78tq9iod8Ichh iKax01MbF82i6F5clHWYZRgjTZ/uEWJYzUuBD+brmPI2hKLj88j18JWKqM7RwSMiTu/wTO1qw8 7uvHe9ndl4MKTZpfAHbGGYuHMSHkEqxwjgZvh1HX7208XwVGSPkWJuOufm8/6RCK5+FH8HrvbW yn2yiCI+cuU3TOauWwqpBUyNlSWH9u0n5G9yUDBn+M97ArruHWj9LXgE+fzJB3Sgr+2f1rIGET zkE=
- References: <firstname.lastname@example.org>
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