[Bug other/70945] Offloading: compatibility of target and offloading toolchains

["tschwinge at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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?