https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #17 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #16)
/* snip */
> diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
> index a73207e5465..8913dacb2b1 100644
> --- a/libgfortran/acinclude.m4
> +++ b/libgfortran/acinclude.m4
> @@ -274,6 +274,9 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
> AC_CACHE_CHECK([whether we have a usable _Float128 type],
> libgfor_cv_have_float128, [
> GCC_TRY_COMPILE_OR_LINK([
> +#ifdef __loongarch__
> +#error On LoongArch we should use long double instead; _Float128 is only
> for backward compatibility
"backward compatibility" is not the correct terminology here... It's actually
some sort of "only for porting existing code easier."
But an annoy thing is "the existing code" may do
#ifdef HAVE_DOUBLEUNDERSCORE_FLOAT128_AND_Q_SUFFIX // probed with autoconf
#include <quadmath.h>
__float128 bad_value = nanq("");
#endif
and we don't have quadmath.h :(. Thus even with Q/q we can just "port existing
code easier" instead of "allowing building existing code."
Or perhaps we should gate __float128 and Q/q with a flag not enabled by
default?
