[LTO] PR 86416 – improve lto1 diagnostic if a mode does not exist (esp. for offloading targets)

[Tobias Burnus]

As long as one compiles for a single target, the message is unlikely to appear.

However, when compiling for offloading, the modes supported on the target
'host' and on the target 'device' can be different. In particular,
'long double' (when larger than double) and '__float128' might not be
available on the device.

This gives currently errors like the following (see PR, comment 0):

> lto1: fatal error: unsupported mode TF  > > compilation terminated. > mkoffload: fatal error: 
x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status

While the device target is hidden in 'x86_64-pc-linux-gnu-accel-nvptx-none-gcc', it might make more sense to 
add it more prominently. Additionally, an average user does
not understand what 'TF' or 'XF' means.

Solutions:
(A) Add the target to the output
(B) Add a better description for the error

I did both in the attached patch, giving:
lto1: fatal error: nvptx-none - 80-bit floating-point numbers unsupported (mode 'XF')
lto1: fatal error: nvptx-none - 128-bit floating-point numbers unsupported (mode 'TF')

* (A) should be fine, I think.

* But I am not 100% happy with (B). I think as interim solution,
it is acceptable as XF/TF are well defined and probably the most
common problem. — Alternatively, one could only commit (A) or
solve it more properly (how?).

* If, e.g., 'long long' or 'integer(kind=16)' are used, only a
generic message is printed.  A message such as "'__float128' not
supported" or "'real(kind=10)' not supported" is more helpful and
supporting all modes and not cherry picking those two would be
useful as well.

The question is how to pass this information to lto-streamer-in.c;
it is available as TYPE_NAME – and, with debugging turned on, this
also gets passed on, but is also not be readily available in
lto_input_mode_table. – Suggestions?


Build on x86-64-gnu-linux and tested without offloading and with nvptx
offloading.

Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto1-diag.diff
Type: text/x-patch
Size: 3440 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20191213/7cc5eb60/attachment.bin>