i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

Message ID YzVtB20h3jGKmYg1@tucnak
State New, archived
Headers
Series i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080] |

Commit Message

Jakub Jelinek Sept. 29, 2022, 10:01 a.m. UTC
  Hi!

The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _Float64x.
All the 4 mangle_type targhook implementations start with
type = TYPE_MAIN_VARIANT (type);
so I think it is cleanest to handle it the same in all and return NULL
before the switches on mode or whatever other tests.
s390 doesn't actually have a bug, but while I was there, having
type = TYPE_MAIN_VARIANT (type);
if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
looked useless to me.

Tested on x86_64, i686 and powerpc64le, ok for trunk?

Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
                 ::= Dh # IEEE 754r half-precision floating point (16 bits)
                 ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific.  Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?

2022-09-29  Jakub Jelinek  <jakub@redhat.com>

	PR c++/107080
	* config/i386/i386.cc (ix86_mangle_type): Always return NULL
	for float128_type_node or float64x_type_node, don't check
	float128t_type_node later on.
	* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
	for float128_type_node or float64x_type_node.
	* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
	Don't check float128_type_node later on.
	* config/s390/s390.cc (s390_mangle_type): Don't use
	TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
	a few lines earlier.

	* g++.dg/cpp23/ext-floating11.C: New test.


	Jakub
  

Comments

Jason Merrill Sept. 30, 2022, 1:54 p.m. UTC | #1
On 9/29/22 06:01, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs on x86 as well as ppc64le (the latter
> with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
> DF64x but e or u9__ieee128 instead.
> Those are the mangling that should be used for the non-standard
> types with the same mode or for long double, but not for _Float64x.
> All the 4 mangle_type targhook implementations start with
> type = TYPE_MAIN_VARIANT (type);
> so I think it is cleanest to handle it the same in all and return NULL
> before the switches on mode or whatever other tests.
> s390 doesn't actually have a bug, but while I was there, having
> type = TYPE_MAIN_VARIANT (type);
> if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
> looked useless to me.
> 
> Tested on x86_64, i686 and powerpc64le, ok for trunk?

OK.

> Note, there is one further problem on aarch64/arm, types with HFmode
> (_Float16 and __fp16) are there mangled as Dh (which is standard
> Itanium mangling:
>                   ::= Dh # IEEE 754r half-precision floating point (16 bits)
>                   ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
> so in theory is also ok, but DF16_ is more specific.  Should we just
> change Dh to DF16_ in those backends, or should __fp16 there be distinct
> type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?

You argued for keeping __float128 separate from _Float128, does the same 
argument not apply to this case?

> And there is csky, which mangles __fp16 (but only if type's name is __fp16,
> not _Float16) as __fp16, that looks clearly invalid to me as it isn't
> valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
> and have it mangled as DF16_ by the generic code?

Sounds good.

> 2022-09-29  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/107080
> 	* config/i386/i386.cc (ix86_mangle_type): Always return NULL
> 	for float128_type_node or float64x_type_node, don't check
> 	float128t_type_node later on.
> 	* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
> 	for float128_type_node or float64x_type_node.
> 	* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
> 	Don't check float128_type_node later on.
> 	* config/s390/s390.cc (s390_mangle_type): Don't use
> 	TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
> 	a few lines earlier.
> 
> 	* g++.dg/cpp23/ext-floating11.C: New test.
> 
> --- gcc/config/i386/i386.cc.jj	2022-09-29 09:13:25.713718513 +0200
> +++ gcc/config/i386/i386.cc	2022-09-29 11:29:20.828358152 +0200
> @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
>         && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
>       return NULL;
>   
> +  if (type == float128_type_node || type == float64x_type_node)
> +    return NULL;
> +
>     switch (TYPE_MODE (type))
>       {
>       case E_BFmode:
> @@ -22735,10 +22738,7 @@ ix86_mangle_type (const_tree type)
>         return "DF16_";
>       case E_TFmode:
>         /* __float128 is "g".  */
> -      if (type == float128t_type_node)
> -	return "g";
> -      /* _Float128 should mangle as "DF128_" done in generic code.  */
> -      return NULL;
> +      return "g";
>       case E_XFmode:
>         /* "long double" or __float80 is "e".  */
>         return "e";
> --- gcc/config/ia64/ia64.cc.jj	2022-09-27 08:03:26.977984661 +0200
> +++ gcc/config/ia64/ia64.cc	2022-09-29 11:29:44.071037677 +0200
> @@ -11225,6 +11225,9 @@ ia64_mangle_type (const_tree type)
>         && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
>       return NULL;
>   
> +  if (type == float128_type_node || type == float64x_type_node)
> +    return NULL;
> +
>     /* On HP-UX, "long double" is mangled as "e" so __float128 is
>        mangled as "e".  */
>     if (!TARGET_HPUX && TYPE_MODE (type) == TFmode)
> --- gcc/config/rs6000/rs6000.cc.jj	2022-09-27 08:03:26.999984363 +0200
> +++ gcc/config/rs6000/rs6000.cc	2022-09-29 11:26:10.290985331 +0200
> @@ -20270,13 +20270,12 @@ rs6000_mangle_type (const_tree type)
>     if (type == bool_int_type_node) return "U6__booli";
>     if (type == bool_long_long_type_node) return "U6__boolx";
>   
> +  if (type == float128_type_node || type == float64x_type_node)
> +    return NULL;
> +
>     if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type)))
>       return "g";
> -  if (SCALAR_FLOAT_TYPE_P (type)
> -      && FLOAT128_IEEE_P (TYPE_MODE (type))
> -      /* _Float128 should mangle as DF128_ (done in generic code)
> -	 rather than u9__ieee128 (used for __ieee128 and __float128).  */
> -      && type != float128_type_node)
> +  if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type)))
>       return "u9__ieee128";
>   
>     if (type == vector_pair_type_node)
> --- gcc/config/s390/s390.cc.jj	2022-09-26 18:47:26.950349802 +0200
> +++ gcc/config/s390/s390.cc	2022-09-29 11:26:51.180421534 +0200
> @@ -7642,8 +7642,7 @@ s390_mangle_type (const_tree type)
>     if (type == s390_builtin_types[BT_BV4SI]) return "U6__booli";
>     if (type == s390_builtin_types[BT_BV2DI]) return "U6__booll";
>   
> -  if (TYPE_MAIN_VARIANT (type) == long_double_type_node
> -      && TARGET_LONG_DOUBLE_128)
> +  if (type == long_double_type_node && TARGET_LONG_DOUBLE_128)
>       return "g";
>   
>     /* For all other types, use normal C++ mangling.  */
> --- gcc/testsuite/g++.dg/cpp23/ext-floating11.C.jj	2022-09-29 11:33:46.331697320 +0200
> +++ gcc/testsuite/g++.dg/cpp23/ext-floating11.C	2022-09-29 11:40:30.610123406 +0200
> @@ -0,0 +1,79 @@
> +// P1467R9 - Extended floating-point types and standard names.
> +// { dg-do compile { target c++23 } }
> +// { dg-options "" }
> +
> +#include "ext-floating.h"
> +
> +#ifdef __STRICT_ANSI__
> +#undef __SIZEOF_FLOAT128__
> +#endif
> +
> +extern "C" void abort ();
> +
> +using namespace std;
> +
> +template <typename T, typename U>
> +int
> +foo (T x, U y) noexcept
> +{
> +  return 3;
> +}
> +
> +int
> +main ()
> +{
> +  if (foo (0.0f, 0.0f) != 3)
> +    abort ();
> +  if (foo (0.0, 0.0) != 3)
> +    abort ();
> +  if (foo (0.0L, 0.0L) != 3)
> +    abort ();
> +#ifdef __STDCPP_FLOAT16_T__
> +  if (foo (0.0f16, 0.0f16) != 3)
> +    abort ();
> +  if (foo (0.0f, 0.0f16) != 3)
> +    abort ();
> +#endif
> +#ifdef __STDCPP_FLOAT32_T__
> +  if (foo (0.0f32, 0.0f32) != 3)
> +    abort ();
> +  if (foo (0.0f, 0.0f32) != 3)
> +    abort ();
> +#endif
> +#ifdef __STDCPP_FLOAT64_T__
> +  if (foo (0.0f64, 0.0f64) != 3)
> +    abort ();
> +  if (foo (0.0, 0.0f64) != 3)
> +    abort ();
> +#endif
> +#ifdef __STDCPP_FLOAT128_T__
> +  if (foo (0.0f128, 0.0f128) != 3)
> +    abort ();
> +  if (foo (0.0L, 0.0f128) != 3)
> +    abort ();
> +#endif
> +#ifdef __STDCPP_BFLOAT16_T__
> +  if (foo (0.0bf16, 0.0bf16) != 3)
> +    abort ();
> +  if (foo (0.0f, 0.0bf16) != 3)
> +    abort ();
> +#endif
> +#ifdef __FLT32X_MANT_DIG__
> +  if (foo (0.0f32x, 0.0f32x) != 3)
> +    abort ();
> +  if (foo (0.0, 0.0f32x) != 3)
> +    abort ();
> +#endif
> +#ifdef __FLT64X_MANT_DIG__
> +  if (foo (0.0f64x, 0.0f64x) != 3)
> +    abort ();
> +  if (foo (0.0L, 0.0f64x) != 3)
> +    abort ();
> +#endif
> +#ifdef __FLT128X_MANT_DIG__
> +  if (foo (0.0f128x, 0.0f128x) != 3)
> +    abort ();
> +  if (foo (0.0L, 0.0f128x) != 3)
> +    abort ();
> +#endif
> +}
> 
> 	Jakub
>
  
Segher Boessenkool Sept. 30, 2022, 3:07 p.m. UTC | #2
Hi!

On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/config/i386/i386.cc.jj	2022-09-29 09:13:25.713718513 +0200
> +++ gcc/config/i386/i386.cc	2022-09-29 11:29:20.828358152 +0200
> @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
>        && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
>      return NULL;
>  
> +  if (type == float128_type_node || type == float64x_type_node)
> +    return NULL;

Is float128_type_node always IEEE QP, never double-double?  I couldn't
find this documented anywhere.  If this is not true, this part of the
patch is incorrect.


Segher
  
Jakub Jelinek Sept. 30, 2022, 3:31 p.m. UTC | #3
On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > --- gcc/config/i386/i386.cc.jj	2022-09-29 09:13:25.713718513 +0200
> > +++ gcc/config/i386/i386.cc	2022-09-29 11:29:20.828358152 +0200
> > @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
> >        && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
> >      return NULL;
> >  
> > +  if (type == float128_type_node || type == float64x_type_node)
> > +    return NULL;
> 
> Is float128_type_node always IEEE QP, never double-double?  I couldn't
> find this documented anywhere.  If this is not true, this part of the
> patch is incorrect.

It is always IEEE quad, if there is no IEEE quad support, it is NULL.
The C++ wording is:

"If the implementation supports an extended floating-point type whose
properties are specified by the ISO/IEC/IEEE 60559 floating-point
interchange format binary128, then the typedef-name std::float128_t is
defined in the header <stdfloat> and names such a type, the macro
__STDCPP_FLOAT128_T__ is defined, and the floating-point literal suffixes
f128 and F128 are supported."
and C:
Types designated:
_FloatN
where N is 16, 32, 64, or ≥128 and a multiple of 32; and, types designated
_DecimalN
where N ≥ 32 and a multiple of 32, are collectively called the interchange floating types. Each
interchange floating type has the IEC 60559 interchange format corresponding to its width (N) and
radix (2 for _FloatN, 10 for _DecimalN). Each interchange floating type is not compatible with any
other type."

So, _Float128 and std::float128_t which we use float128_type_node for
must be IEEE binary128, nothing else.

Internally, it is implemented by using targetm.floatn_mode hook to query
which mode if any is the IEEE one with corresponding width.

	Jakub
  
Segher Boessenkool Sept. 30, 2022, 3:50 p.m. UTC | #4
On Fri, Sep 30, 2022 at 05:31:26PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > --- gcc/config/i386/i386.cc.jj	2022-09-29 09:13:25.713718513 +0200
> > > +++ gcc/config/i386/i386.cc	2022-09-29 11:29:20.828358152 +0200
> > > @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
> > >        && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
> > >      return NULL;
> > >  
> > > +  if (type == float128_type_node || type == float64x_type_node)
> > > +    return NULL;
> > 
> > Is float128_type_node always IEEE QP, never double-double?  I couldn't
> > find this documented anywhere.  If this is not true, this part of the
> > patch is incorrect.
> 
> It is always IEEE quad, if there is no IEEE quad support, it is NULL.
> The C++ wording is:
> 
> "If the implementation supports an extended floating-point type whose
> properties are specified by the ISO/IEC/IEEE 60559 floating-point
> interchange format binary128, then the typedef-name std::float128_t is
> defined in the header <stdfloat> and names such a type, the macro
> __STDCPP_FLOAT128_T__ is defined, and the floating-point literal suffixes
> f128 and F128 are supported."
> and C:
> Types designated:
> _FloatN
> where N is 16, 32, 64, or ≥128 and a multiple of 32; and, types designated
> _DecimalN
> where N ≥ 32 and a multiple of 32, are collectively called the interchange floating types. Each
> interchange floating type has the IEC 60559 interchange format corresponding to its width (N) and
> radix (2 for _FloatN, 10 for _DecimalN). Each interchange floating type is not compatible with any
> other type."
> 
> So, _Float128 and std::float128_t which we use float128_type_node for
> must be IEEE binary128, nothing else.

Great :-)

> Internally, it is implemented by using targetm.floatn_mode hook to query
> which mode if any is the IEEE one with corresponding width.

tree.h says just
/* Names for individual types (code should normally iterate over all
   such types; these are only for back-end use, or in contexts such as
   *.def where iteration is not possible).  */
and there is nothing whatsoever in doc/.  Looking at the current
implementation never shows intent :-(


Segher
  

Patch

--- gcc/config/i386/i386.cc.jj	2022-09-29 09:13:25.713718513 +0200
+++ gcc/config/i386/i386.cc	2022-09-29 11:29:20.828358152 +0200
@@ -22725,6 +22725,9 @@  ix86_mangle_type (const_tree type)
       && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
     return NULL;
 
+  if (type == float128_type_node || type == float64x_type_node)
+    return NULL;
+
   switch (TYPE_MODE (type))
     {
     case E_BFmode:
@@ -22735,10 +22738,7 @@  ix86_mangle_type (const_tree type)
       return "DF16_";
     case E_TFmode:
       /* __float128 is "g".  */
-      if (type == float128t_type_node)
-	return "g";
-      /* _Float128 should mangle as "DF128_" done in generic code.  */
-      return NULL;
+      return "g";
     case E_XFmode:
       /* "long double" or __float80 is "e".  */
       return "e";
--- gcc/config/ia64/ia64.cc.jj	2022-09-27 08:03:26.977984661 +0200
+++ gcc/config/ia64/ia64.cc	2022-09-29 11:29:44.071037677 +0200
@@ -11225,6 +11225,9 @@  ia64_mangle_type (const_tree type)
       && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
     return NULL;
 
+  if (type == float128_type_node || type == float64x_type_node)
+    return NULL;
+
   /* On HP-UX, "long double" is mangled as "e" so __float128 is
      mangled as "e".  */
   if (!TARGET_HPUX && TYPE_MODE (type) == TFmode)
--- gcc/config/rs6000/rs6000.cc.jj	2022-09-27 08:03:26.999984363 +0200
+++ gcc/config/rs6000/rs6000.cc	2022-09-29 11:26:10.290985331 +0200
@@ -20270,13 +20270,12 @@  rs6000_mangle_type (const_tree type)
   if (type == bool_int_type_node) return "U6__booli";
   if (type == bool_long_long_type_node) return "U6__boolx";
 
+  if (type == float128_type_node || type == float64x_type_node)
+    return NULL;
+
   if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type)))
     return "g";
-  if (SCALAR_FLOAT_TYPE_P (type)
-      && FLOAT128_IEEE_P (TYPE_MODE (type))
-      /* _Float128 should mangle as DF128_ (done in generic code)
-	 rather than u9__ieee128 (used for __ieee128 and __float128).  */
-      && type != float128_type_node)
+  if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type)))
     return "u9__ieee128";
 
   if (type == vector_pair_type_node)
--- gcc/config/s390/s390.cc.jj	2022-09-26 18:47:26.950349802 +0200
+++ gcc/config/s390/s390.cc	2022-09-29 11:26:51.180421534 +0200
@@ -7642,8 +7642,7 @@  s390_mangle_type (const_tree type)
   if (type == s390_builtin_types[BT_BV4SI]) return "U6__booli";
   if (type == s390_builtin_types[BT_BV2DI]) return "U6__booll";
 
-  if (TYPE_MAIN_VARIANT (type) == long_double_type_node
-      && TARGET_LONG_DOUBLE_128)
+  if (type == long_double_type_node && TARGET_LONG_DOUBLE_128)
     return "g";
 
   /* For all other types, use normal C++ mangling.  */
--- gcc/testsuite/g++.dg/cpp23/ext-floating11.C.jj	2022-09-29 11:33:46.331697320 +0200
+++ gcc/testsuite/g++.dg/cpp23/ext-floating11.C	2022-09-29 11:40:30.610123406 +0200
@@ -0,0 +1,79 @@ 
+// P1467R9 - Extended floating-point types and standard names.
+// { dg-do compile { target c++23 } }
+// { dg-options "" }
+
+#include "ext-floating.h"
+
+#ifdef __STRICT_ANSI__
+#undef __SIZEOF_FLOAT128__
+#endif
+
+extern "C" void abort ();
+
+using namespace std;
+
+template <typename T, typename U> 
+int
+foo (T x, U y) noexcept
+{
+  return 3;
+}
+
+int
+main ()
+{
+  if (foo (0.0f, 0.0f) != 3)
+    abort ();
+  if (foo (0.0, 0.0) != 3)
+    abort ();
+  if (foo (0.0L, 0.0L) != 3)
+    abort ();
+#ifdef __STDCPP_FLOAT16_T__
+  if (foo (0.0f16, 0.0f16) != 3)
+    abort ();
+  if (foo (0.0f, 0.0f16) != 3)
+    abort ();
+#endif
+#ifdef __STDCPP_FLOAT32_T__
+  if (foo (0.0f32, 0.0f32) != 3)
+    abort ();
+  if (foo (0.0f, 0.0f32) != 3)
+    abort ();
+#endif
+#ifdef __STDCPP_FLOAT64_T__
+  if (foo (0.0f64, 0.0f64) != 3)
+    abort ();
+  if (foo (0.0, 0.0f64) != 3)
+    abort ();
+#endif
+#ifdef __STDCPP_FLOAT128_T__
+  if (foo (0.0f128, 0.0f128) != 3)
+    abort ();
+  if (foo (0.0L, 0.0f128) != 3)
+    abort ();
+#endif
+#ifdef __STDCPP_BFLOAT16_T__
+  if (foo (0.0bf16, 0.0bf16) != 3)
+    abort ();
+  if (foo (0.0f, 0.0bf16) != 3)
+    abort ();
+#endif
+#ifdef __FLT32X_MANT_DIG__
+  if (foo (0.0f32x, 0.0f32x) != 3)
+    abort ();
+  if (foo (0.0, 0.0f32x) != 3)
+    abort ();
+#endif
+#ifdef __FLT64X_MANT_DIG__
+  if (foo (0.0f64x, 0.0f64x) != 3)
+    abort ();
+  if (foo (0.0L, 0.0f64x) != 3)
+    abort ();
+#endif
+#ifdef __FLT128X_MANT_DIG__
+  if (foo (0.0f128x, 0.0f128x) != 3)
+    abort ();
+  if (foo (0.0L, 0.0f128x) != 3)
+    abort ();
+#endif
+}