https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2016-05-13
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 38484
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38484&action=edit
0001-function_glibc_finite_math.patch
(In reply to Alexander Monakov from comment #1)
> Basically I'd say that host compilation environment establishes an ABI
> baseline that the accel environment must follow.
Generally, ACK.
> In your finite-math
> example, the problem exists due to an ABI extension in Glibc (note that the
> custom name could equally happen to be __glibc_log_finite). You'd see the
> same issue trying to run a new binary on old Glibc systems that didn't have
> that symbol yet, and now Glibc itself is bound to carry that entrypoint
> forever.
ACK.
> And note that the issue is not limited to math symbols either: with
> -D_FORTIFY_SOURCE, plain 'printf' may become '__printf_chk', which would
> also fail to link on Newlib.
ACK, but let's concentrate on the math functions for the moment.
> Is there any actual issue with Fortran functions? [...]
That was meant to be a "motivational example", why users may expect to be able
to use math functions also in offloaded C/C++ regions.
I'm attaching a patch that shows a different approach, instead of adding a lot
of glibc-specific "__[function]_finite" entry points to the nvptx newlib, which
don't belong into there, really.
Basically, we add a new property function_glibc_finite_math
(gcc/coretypes.h:enum function_class), stream that in the target compiler
(gcc/lto-cgraph.c:output_offload_tables), and when reading it back in in the
offloading compilers (gcc/lto-cgraph.c:input_offload_tables), if the offloading
compiler's property doesn't match the of the target compiler, for all
references to external math functions, we 'check whether the assembler name for
"[function]" has been set to "__[function]_finite" [...], and if yes, reset
it'.
We could get rid of this heuristic (the property function_glibc_finite_math in
combination with matching declarations' names) if the target compiler's early
code transformation stages would accurately "describe" what they're doing, but
that sounds like having to add some special/new "attributes" to glibc's
<bits/math-finite.h>, which sounds more complicated. I think the heuristic is
safe enough; symbol names prefixed with an underscore are in the implementation
namespace.
What do you think of that?
