https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
> I think the output by LTO is correct but not very helpful:
>
> lto1: fatal error: unsupported mode 'XF' (for long double)
> lto1: fatal error: unsupported mode 'TF' (for __float128)
>
> I think when generating code for offloading, this must be more explicit like:
>
> nvptx-none does not support 80-bit floating-point numbers
> nvptx-none does not support 128-bit floating-point numbers
Seems as if 'lto1' does not know about the target for which it has been
compiled.
Otherwise, would a patch along the following lines make sense?
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1700,7 +1700,18 @@ lto_input_mode_table (struct lto_file_decl_data
}
/* FALLTHRU */
default:
- fatal_error (UNKNOWN_LOCATION, "unsupported mode %qs", mname);
+ /* Especially for offloading compilers, it helps to have a more
+ readable error message. See also target.def. */
+ if (mname[0] == 'X' && mname[1] == 'F')
+ fatal_error (UNKNOWN_LOCATION,
+ "80-bit floating-point numbers unsupported (mode "
+ "%qs)", mname);
+ else if (mname[0] == 'T' && mname[1] == 'F')
+ fatal_error (UNKNOWN_LOCATION,
+ "128-bit floating-point numbers unsupported (mode
"
+ "%qs)", mname);
+ else
+ fatal_error (UNKNOWN_LOCATION, "unsupported mode %qs", mname);
break;
}
}
