https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127589
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
If I add a diagnostic in lto_input_mode_table between
const char *mname = bp_unpack_indexed_string (data_in, &bp, &mname_len);
and
if (pass == 2)
I get for _Float128:
lto1: warning: Processing ‘QI’ (8 bits) in pass 3
lto1: warning: Processing ‘SI’ (32 bits) in pass 3
lto1: warning: Processing ‘DI’ (64 bits) in pass 3
lto1: warning: Processing ‘TF’ (128 bits) in pass 2
lto1: fatal error: nvptx-none - 128-bit-precision floating-point numbers
unsupported (mode ‘TF’)
However, for _Float16, I get:
lto1: warning: Processing ‘QI’ (8 bits) in pass 3
lto1: warning: Processing ‘SI’ (32 bits) in pass 3
lto1: warning: Processing ‘DI’ (64 bits) in pass 3
lto1: warning: Processing ‘HF’ (16 bits) in pass 3
lto1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in lto_fixup_prevailing_type, at
lto/lto-common.cc:1006
As the latter has 'pass = 2', it continues, that's for
"HF" alias "ieee_half".
Looking at NVPTX's and AMDGCN's
const char *const mode_name[NUM_MACHINE_MODES] =
They both list "HF" but not "TF" - thus, it is not surprising that this
check passes.
* * *
OK THIS IS ODD for Both Nvptx and AMD GCN:
* Trying to use _Float16 in the code and running the device cc1 reports:
HF is not supported.
* However, config/{nvptx,gcn} has plenty of code to handle "HF"
not just listening it in 'mode_name'
Thus:
* Why does it report _Float16 as not supported via cc1?
* Why does it crash when using it?
