[PATCH] Fix decimal floating-point LTO streaming for offloading compilation

[Julian Brown]

As mentioned in PR91985, offloading compilation is broken at present
because of an issue with LTO streaming. With thanks to Joseph for
hints, here's a solution.

Unlike e.g. the _FloatN types, when decimal floating-point types are
enabled, common tree nodes are created for each float type size (e.g.
dfloat32_type_node) and also a pointer to each type is created
(e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits
these like:

  <float:32>     (dfloat32_type_node)
  <float:64>     (dfloat64_type_node)
  <float:128>    (dfloat128_type_node)
  <float:32> *   (dfloat32_ptr_type_node)
  <float:32>
  <float:64> *   (dfloat64_ptr_type_node)
  <float:64>
  <float:128> *  (dfloat128_ptr_type_node)
  <float:128>

I.e., with explicit emission of a copy of the pointed-to type following
the pointer itself.

When DFP is disabled, we instead get:

  <<< error >>>
  <<< error >>>
  <<< error >>>
  <<< error >>>
  <<< error >>>
  <<< error >>>

So, the number of nodes emitted during LTO write-out in the host/read-in
in the offload compiler do not match.

This patch restores the number of nodes emitted by creating
dfloatN_ptr_type_node as generic pointers rather than treating them as
flat error_type_nodes. I don't think there's an easy way of creating an
"error_type_node *", nor do I know if that would really be preferable.

Tested with offloading to NVPTX & bootstrapped. OK to apply?

Thanks,

Julian

ChangeLog

        gcc/
        * tree.c (build_common_tree_nodes): Use pointer type for
        dfloat32_ptr_type_node, dfloat64_ptr_type_node and
        dfloat128_ptr_type_node when decimal floating point support
        is disabled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-dfp-lto-streaming-1.diff
Type: text/x-patch
Size: 1253 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20191128/f4b2dbf5/attachment.bin>