*ping*
On 12/13/19 3:34 PM, Tobias Burnus wrote:
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
