* [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]
@ 2022-01-24 19:34 Jakub Jelinek
2022-01-24 22:14 ` Mark Wielaard
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2022-01-24 19:34 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches, Mark Wielaard, Ulrich Weigand
Hi!
As mentioned in the PR, we emit the same
.uleb128 0x3 # (DIE (0x42) DW_TAG_base_type)
.byte 0x10 # DW_AT_byte_size
.byte 0x4 # DW_AT_encoding
.4byte .LASF2 # DW_AT_name: "long double"
(0x4 is DW_ATE_float) whether we on powerpc64le-linux use
-mabi=ibmlongdouble or -mabi=ieeelongdouble.
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-January/004859.html
lists some options how to handle that and Ulrich mentioned it in his
Cauldron talk too:
https://slideslive.com/38902369/precise-target-floatingpoint-emulation-in-gdb?ref=account-folder-9307-folders
pages 8-16.
The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
equal to corresponding HP extensions) instead of DW_ATE_float,
another possibility would be DW_ATE_GNU_precision attribute on the
DW_TAG_base_type that would for these multiple 16-byte float cases
(or always) emit a precision (113 for binary128, 106 for double double),
yet another one is what Ulrich mentions in his slides
(DW_AT_GNU_encoding_variant {0,1}).
I didn't get any responses to my dwarf discuss mails yet, on IRC
Jason preferred a DW_AT_encoding change while Mark prefered
DW_AT_GNU_precision. In any case, all of these are just GNU extensions,
if/when DWARF standardizes something else, we can use it for -gdwarf-6
or later.
Bootstrap/regtest pending on powerpc64le-linux (both defaulting to
ibmlongdouble and ieeelongdouble), ok for trunk if it passes?
2022-01-24 Jakub Jelinek <jakub@redhat.com>
PR debug/104194
* dwarf2.def (DW_ATE_GNU_float128, DW_ATE_GNU_complex_float128): New
DW_AT_encoding values.
* dwarf2out.c (base_type_die): Use DW_ATE_GNU_float128 instead of
DW_ATE_float for 16-byte non-composite mode if target supports also
composite modes. Similarly use DW_AT_GNU_complex_float128 instead
of DW_ATE_complex_float for 32-byte complex mode with non-composite
inner mode if target supports also composite modes.
--- include/dwarf2.def.jj 2022-01-11 23:11:23.593273249 +0100
+++ include/dwarf2.def 2022-01-24 17:46:08.699138085 +0100
@@ -732,11 +732,20 @@ DW_ATE (DW_ATE_ASCII, 0x12)
DW_ATE_DUP (DW_ATE_lo_user, 0x80)
DW_ATE_DUP (DW_ATE_hi_user, 0xff)
+/* GNU extensions. */
+DW_ATE (DW_ATE_GNU_float128, 0x82) /* Floating-point (IEEE quad precision if
+ there are multiple 16-byte floating
+ formats). */
+DW_ATE (DW_ATE_GNU_complex_float128, 0x83) /* Complex fp
+ (IEEE quad precision if there
+ are multiple 16-byte floating
+ formats). */
+
/* HP extensions. */
DW_ATE (DW_ATE_HP_float80, 0x80) /* Floating-point (80 bit). */
DW_ATE (DW_ATE_HP_complex_float80, 0x81) /* Complex floating-point (80 bit). */
-DW_ATE (DW_ATE_HP_float128, 0x82) /* Floating-point (128 bit). */
-DW_ATE (DW_ATE_HP_complex_float128, 0x83) /* Complex fp (128 bit). */
+DW_ATE_DUP (DW_ATE_HP_float128, 0x82) /* Floating-point (128 bit). */
+DW_ATE_DUP (DW_ATE_HP_complex_float128, 0x83) /* Complex fp (128 bit). */
DW_ATE (DW_ATE_HP_floathpintel, 0x84) /* Floating-point (82 bit IA64). */
DW_ATE (DW_ATE_HP_imaginary_float80, 0x85)
DW_ATE (DW_ATE_HP_imaginary_float128, 0x86)
--- gcc/dwarf2out.cc.jj 2022-01-20 11:58:12.632304188 +0100
+++ gcc/dwarf2out.cc 2022-01-24 18:27:12.862642858 +0100
@@ -13260,7 +13260,23 @@ base_type_die (tree type, bool reverse)
encoding = DW_ATE_lo_user;
}
else
- encoding = DW_ATE_float;
+ {
+ encoding = DW_ATE_float;
+
+ /* On targets like PowerPC which support both
+ a double double 16-byte floating mode
+ (MODE_COMPOSITE_P) and some other 16-byte
+ floating mode (IEEE quad precision), use
+ DW_ATE_GNU_float128 instead of DW_ATE_float
+ for the latter. */
+ machine_mode mode;
+ if (known_eq (GET_MODE_SIZE (TYPE_MODE (type)), 16)
+ && !MODE_COMPOSITE_P (TYPE_MODE (type)))
+ FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT)
+ if (known_eq (GET_MODE_SIZE (mode), 16)
+ && MODE_COMPOSITE_P (mode))
+ encoding = DW_ATE_GNU_float128;
+ }
break;
case FIXED_POINT_TYPE:
@@ -13276,7 +13292,23 @@ base_type_die (tree type, bool reverse)
a user defined type for it. */
case COMPLEX_TYPE:
if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE)
- encoding = DW_ATE_complex_float;
+ {
+ encoding = DW_ATE_complex_float;
+
+ /* On targets like PowerPC which support both
+ a double double 16-byte floating mode
+ (MODE_COMPOSITE_P) and some other 16-byte
+ floating mode (IEEE quad precision), use
+ DW_ATE_GNU_complex_float128 instead of
+ DW_ATE_float for the latter. */
+ machine_mode mode;
+ if (known_eq (GET_MODE_SIZE (TYPE_MODE (type)), 32)
+ && !MODE_COMPOSITE_P (TYPE_MODE (TREE_TYPE (type))))
+ FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT)
+ if (known_eq (GET_MODE_SIZE (mode), 16)
+ && MODE_COMPOSITE_P (mode))
+ encoding = DW_ATE_GNU_complex_float128;
+ }
else
encoding = DW_ATE_lo_user;
break;
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]
2022-01-24 19:34 [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194] Jakub Jelinek
@ 2022-01-24 22:14 ` Mark Wielaard
2022-01-24 22:26 ` Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Mark Wielaard @ 2022-01-24 22:14 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches, Ulrich Weigand
Hi,
On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote:
> The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
> equal to corresponding HP extensions) instead of DW_ATE_float,
> another possibility would be DW_ATE_GNU_precision attribute on the
> DW_TAG_base_type that would for these multiple 16-byte float cases
> (or always) emit a precision (113 for binary128, 106 for double double),
> yet another one is what Ulrich mentions in his slides
> (DW_AT_GNU_encoding_variant {0,1}).
>
> I didn't get any responses to my dwarf discuss mails yet, on IRC
> Jason preferred a DW_AT_encoding change while Mark prefered
> DW_AT_GNU_precision. In any case, all of these are just GNU extensions,
> if/when DWARF standardizes something else, we can use it for -gdwarf-6
> or later.
When we try to standardize this (in DWARF6) then I think I prefer
having a separate attribute which specifies the precision, just like
we already use DW_AT_byte_size to specify the size. That might also
help with the different float16 encodings.
But if we need a solution now (for gcc12) then using a new DW_ATE_GNU
extension seems more practical.
Cheers,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]
2022-01-24 22:14 ` Mark Wielaard
@ 2022-01-24 22:26 ` Jakub Jelinek
2022-01-25 11:02 ` [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194] Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2022-01-24 22:26 UTC (permalink / raw)
To: Mark Wielaard; +Cc: Jason Merrill, gcc-patches, Ulrich Weigand
On Mon, Jan 24, 2022 at 11:14:41PM +0100, Mark Wielaard wrote:
> On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote:
> > The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
> > equal to corresponding HP extensions) instead of DW_ATE_float,
> > another possibility would be DW_ATE_GNU_precision attribute on the
> > DW_TAG_base_type that would for these multiple 16-byte float cases
> > (or always) emit a precision (113 for binary128, 106 for double double),
> > yet another one is what Ulrich mentions in his slides
> > (DW_AT_GNU_encoding_variant {0,1}).
> >
> > I didn't get any responses to my dwarf discuss mails yet, on IRC
> > Jason preferred a DW_AT_encoding change while Mark prefered
> > DW_AT_GNU_precision. In any case, all of these are just GNU extensions,
> > if/when DWARF standardizes something else, we can use it for -gdwarf-6
> > or later.
>
> When we try to standardize this (in DWARF6) then I think I prefer
> having a separate attribute which specifies the precision, just like
> we already use DW_AT_byte_size to specify the size. That might also
> help with the different float16 encodings.
>
> But if we need a solution now (for gcc12) then using a new DW_ATE_GNU
> extension seems more practical.
Actually for debuggers, DW_AT_GNU_precision might be better.
I think debuggers will just give up on unknown DW_ATE_*, they really don't
know how to handle it.
While if they see an unknown attribute on the base type, I'd think they'd
ignore it, so treat the IEEE quad "long double" as IBM double double
instead, but e.g. for __float128 or __ibm128 would be using the DW_AT_name
heuristics handled fine.
Yet another short term solution might be not use DW_TAG_base_type
for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
with DW_AT_name "long double" to __float128 DW_TAG_base_type.
I bet gdb would even handle it without any changes, but of course, it would
be larger than the other proposed changes.
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194]
2022-01-24 22:26 ` Jakub Jelinek
@ 2022-01-25 11:02 ` Jakub Jelinek
2022-01-25 19:24 ` Jason Merrill
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2022-01-25 11:02 UTC (permalink / raw)
To: Jason Merrill, Mark Wielaard, Ulrich Weigand; +Cc: gcc-patches
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
> I bet gdb would even handle it without any changes, but of course, it would
> be larger than the other proposed changes.
Here it is implemented.
Testcases I've played with are e.g.:
__ibm128 a;
long double b;
_Complex long double c;
static __attribute__((noinline)) int
foo (long double d)
{
long double e = d + 1.0L;
return 0;
}
int
main ()
{
a = 1.0;
b = 2.0;
c = 5.0 + 6.0i;
return foo (7.0L);
}
and
real(kind=16) :: a
complex(kind=16) :: b
a = 1.0
b = 2.0
end
Printing the values of the variables works well,
p &b or p &c shows pointer to the correct type, just
ptype b or ptype c prints _Float128 instead of
long double or complex _Float128 instead of complex long double.
Even worse in fortran where obviously _Float128 or
complex _Float128 aren't valid types, but as GDB knows them by name,
it is just ptype that is weird.
Is this ok for trunk until we get an agreement on which extension
to use (different DW_ATE_*, or DW_AT_GNU_precision or
DW_ATE_GNU_encoding_variant)?
2022-01-25 Jakub Jelinek <jakub@redhat.com>
PR debug/104194
* dwarf2out.cc (long_double_as_float128): New function.
(modified_type_die): For powerpc64le IEEE 754 quad long double
and complex long double emit those as DW_TAG_typedef to
_Float128 or complex _Float128 base type.
--- gcc/dwarf2out.cc.jj 2022-01-25 05:47:53.987454934 +0100
+++ gcc/dwarf2out.cc 2022-01-25 11:54:25.100522089 +0100
@@ -13568,6 +13568,47 @@ qualified_die_p (dw_die_ref die, int *ma
return type;
}
+/* If TYPE is long double or complex long double that
+ should be emitted as artificial typedef to _Float128 or
+ complex _Float128, return the type it should be emitted as.
+ This is done in case the target already supports 16-byte
+ composite floating point type (ibm_extended_format). */
+
+static tree
+long_double_as_float128 (tree type)
+{
+ if (type != long_double_type_node
+ && type != complex_long_double_type_node)
+ return NULL_TREE;
+
+ machine_mode mode, fmode;
+ if (TREE_CODE (type) == COMPLEX_TYPE)
+ mode = TYPE_MODE (TREE_TYPE (type));
+ else
+ mode = TYPE_MODE (type);
+ if (known_eq (GET_MODE_SIZE (mode), 16) && !MODE_COMPOSITE_P (mode))
+ FOR_EACH_MODE_IN_CLASS (fmode, MODE_FLOAT)
+ if (known_eq (GET_MODE_SIZE (fmode), 16)
+ && MODE_COMPOSITE_P (fmode))
+ {
+ if (type == long_double_type_node)
+ {
+ if (float128_type_node
+ && (TYPE_MODE (float128_type_node)
+ == TYPE_MODE (type)))
+ return float128_type_node;
+ return NULL_TREE;
+ }
+ for (int i = 0; i < NUM_FLOATN_NX_TYPES; i++)
+ if (COMPLEX_FLOATN_NX_TYPE_NODE (i) != NULL_TREE
+ && (TYPE_MODE (COMPLEX_FLOATN_NX_TYPE_NODE (i))
+ == TYPE_MODE (type)))
+ return COMPLEX_FLOATN_NX_TYPE_NODE (i);
+ }
+
+ return NULL_TREE;
+}
+
/* Given a pointer to an arbitrary ..._TYPE tree node, return a debugging
entry that chains the modifiers specified by CV_QUALS in front of the
given type. REVERSE is true if the type is to be interpreted in the
@@ -13848,7 +13889,32 @@ modified_type_die (tree type, int cv_qua
}
else if (is_base_type (type))
{
- mod_type_die = base_type_die (type, reverse);
+ /* If a target supports long double as different floating point
+ modes with the same 16-byte size, use normal DW_TAG_base_type
+ only for the composite (ibm_extended_real_format) type and
+ for the other for the time being emit instead a "_Float128"
+ or "complex _Float128" DW_TAG_base_type and a "long double"
+ or "complex long double" typedef to it. */
+ if (tree other_type = long_double_as_float128 (type))
+ {
+ dw_die_ref other_die;
+ if (TYPE_NAME (other_type))
+ other_die
+ = modified_type_die (other_type, TYPE_UNQUALIFIED, reverse,
+ context_die);
+ else
+ {
+ other_die = base_type_die (type, reverse);
+ add_child_die (comp_unit_die (), other_die);
+ add_name_attribute (other_die,
+ TREE_CODE (type) == COMPLEX_TYPE
+ ? "complex _Float128" : "_Float128");
+ }
+ mod_type_die = new_die_raw (DW_TAG_typedef);
+ add_AT_die_ref (mod_type_die, DW_AT_type, other_die);
+ }
+ else
+ mod_type_die = base_type_die (type, reverse);
/* The DIE with DW_AT_endianity is placed right after the naked DIE. */
if (reverse_base_type)
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194]
2022-01-25 11:02 ` [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194] Jakub Jelinek
@ 2022-01-25 19:24 ` Jason Merrill
2022-01-25 19:36 ` Jakub Jelinek
0 siblings, 1 reply; 6+ messages in thread
From: Jason Merrill @ 2022-01-25 19:24 UTC (permalink / raw)
To: Jakub Jelinek, Mark Wielaard, Ulrich Weigand; +Cc: gcc-patches
On 1/25/22 06:02, Jakub Jelinek wrote:
> On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
>> Yet another short term solution might be not use DW_TAG_base_type
>> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
>> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
>> I bet gdb would even handle it without any changes, but of course, it would
>> be larger than the other proposed changes.
>
> Here it is implemented.
>
> Testcases I've played with are e.g.:
> __ibm128 a;
> long double b;
> _Complex long double c;
>
> static __attribute__((noinline)) int
> foo (long double d)
> {
> long double e = d + 1.0L;
> return 0;
> }
>
> int
> main ()
> {
> a = 1.0;
> b = 2.0;
> c = 5.0 + 6.0i;
> return foo (7.0L);
> }
> and
> real(kind=16) :: a
> complex(kind=16) :: b
> a = 1.0
> b = 2.0
> end
>
> Printing the values of the variables works well,
> p &b or p &c shows pointer to the correct type, just
> ptype b or ptype c prints _Float128 instead of
> long double or complex _Float128 instead of complex long double.
> Even worse in fortran where obviously _Float128 or
> complex _Float128 aren't valid types, but as GDB knows them by name,
> it is just ptype that is weird.
>
> Is this ok for trunk until we get an agreement on which extension
> to use (different DW_ATE_*, or DW_AT_GNU_precision or
> DW_ATE_GNU_encoding_variant)?
>
> 2022-01-25 Jakub Jelinek <jakub@redhat.com>
>
> PR debug/104194
> * dwarf2out.cc (long_double_as_float128): New function.
> (modified_type_die): For powerpc64le IEEE 754 quad long double
> and complex long double emit those as DW_TAG_typedef to
> _Float128 or complex _Float128 base type.
>
> --- gcc/dwarf2out.cc.jj 2022-01-25 05:47:53.987454934 +0100
> +++ gcc/dwarf2out.cc 2022-01-25 11:54:25.100522089 +0100
> @@ -13568,6 +13568,47 @@ qualified_die_p (dw_die_ref die, int *ma
> return type;
> }
>
> +/* If TYPE is long double or complex long double that
> + should be emitted as artificial typedef to _Float128 or
> + complex _Float128, return the type it should be emitted as.
> + This is done in case the target already supports 16-byte
> + composite floating point type (ibm_extended_format). */
> +
> +static tree
> +long_double_as_float128 (tree type)
> +{
> + if (type != long_double_type_node
> + && type != complex_long_double_type_node)
> + return NULL_TREE;
> +
> + machine_mode mode, fmode;
> + if (TREE_CODE (type) == COMPLEX_TYPE)
> + mode = TYPE_MODE (TREE_TYPE (type));
> + else
> + mode = TYPE_MODE (type);
> + if (known_eq (GET_MODE_SIZE (mode), 16) && !MODE_COMPOSITE_P (mode))
> + FOR_EACH_MODE_IN_CLASS (fmode, MODE_FLOAT)
> + if (known_eq (GET_MODE_SIZE (fmode), 16)
> + && MODE_COMPOSITE_P (fmode))
> + {
> + if (type == long_double_type_node)
> + {
> + if (float128_type_node
> + && (TYPE_MODE (float128_type_node)
> + == TYPE_MODE (type)))
> + return float128_type_node;
> + return NULL_TREE;
> + }
> + for (int i = 0; i < NUM_FLOATN_NX_TYPES; i++)
> + if (COMPLEX_FLOATN_NX_TYPE_NODE (i) != NULL_TREE
> + && (TYPE_MODE (COMPLEX_FLOATN_NX_TYPE_NODE (i))
> + == TYPE_MODE (type)))
> + return COMPLEX_FLOATN_NX_TYPE_NODE (i);
> + }
Do we really need this loop to determine if the target supports two
different long doubles? This seems like a complicated way of saying
"if this is IEEE 128-bit long double and the target also supports IBM
double double", return _Float128."
But OK.
> +
> + return NULL_TREE;
> +}
> +
> /* Given a pointer to an arbitrary ..._TYPE tree node, return a debugging
> entry that chains the modifiers specified by CV_QUALS in front of the
> given type. REVERSE is true if the type is to be interpreted in the
> @@ -13848,7 +13889,32 @@ modified_type_die (tree type, int cv_qua
> }
> else if (is_base_type (type))
> {
> - mod_type_die = base_type_die (type, reverse);
> + /* If a target supports long double as different floating point
> + modes with the same 16-byte size, use normal DW_TAG_base_type
> + only for the composite (ibm_extended_real_format) type and
> + for the other for the time being emit instead a "_Float128"
> + or "complex _Float128" DW_TAG_base_type and a "long double"
> + or "complex long double" typedef to it. */
> + if (tree other_type = long_double_as_float128 (type))
> + {
> + dw_die_ref other_die;
> + if (TYPE_NAME (other_type))
> + other_die
> + = modified_type_die (other_type, TYPE_UNQUALIFIED, reverse,
> + context_die);
> + else
> + {
> + other_die = base_type_die (type, reverse);
> + add_child_die (comp_unit_die (), other_die);
> + add_name_attribute (other_die,
> + TREE_CODE (type) == COMPLEX_TYPE
> + ? "complex _Float128" : "_Float128");
> + }
> + mod_type_die = new_die_raw (DW_TAG_typedef);
> + add_AT_die_ref (mod_type_die, DW_AT_type, other_die);
> + }
> + else
> + mod_type_die = base_type_die (type, reverse);
>
> /* The DIE with DW_AT_endianity is placed right after the naked DIE. */
> if (reverse_base_type)
>
>
> Jakub
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194]
2022-01-25 19:24 ` Jason Merrill
@ 2022-01-25 19:36 ` Jakub Jelinek
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Jelinek @ 2022-01-25 19:36 UTC (permalink / raw)
To: Jason Merrill; +Cc: Mark Wielaard, Ulrich Weigand, gcc-patches
On Tue, Jan 25, 2022 at 02:24:34PM -0500, Jason Merrill wrote:
> > + machine_mode mode, fmode;
> > + if (TREE_CODE (type) == COMPLEX_TYPE)
> > + mode = TYPE_MODE (TREE_TYPE (type));
> > + else
> > + mode = TYPE_MODE (type);
> > + if (known_eq (GET_MODE_SIZE (mode), 16) && !MODE_COMPOSITE_P (mode))
> > + FOR_EACH_MODE_IN_CLASS (fmode, MODE_FLOAT)
> > + if (known_eq (GET_MODE_SIZE (fmode), 16)
> > + && MODE_COMPOSITE_P (fmode))
> > + {
> > + if (type == long_double_type_node)
> > + {
> > + if (float128_type_node
> > + && (TYPE_MODE (float128_type_node)
> > + == TYPE_MODE (type)))
> > + return float128_type_node;
> > + return NULL_TREE;
> > + }
> > + for (int i = 0; i < NUM_FLOATN_NX_TYPES; i++)
> > + if (COMPLEX_FLOATN_NX_TYPE_NODE (i) != NULL_TREE
> > + && (TYPE_MODE (COMPLEX_FLOATN_NX_TYPE_NODE (i))
> > + == TYPE_MODE (type)))
> > + return COMPLEX_FLOATN_NX_TYPE_NODE (i);
> > + }
>
> Do we really need this loop to determine if the target supports two
> different long doubles? This seems like a complicated way of saying
> "if this is IEEE 128-bit long double and the target also supports IBM double
> double", return _Float128."
The outermost if and FOR_EACH_MODE_IN_CLASS in it are checking if it is
essentially ppc64le-linux with -mabi=ieeelongdouble, i.e. whether long double
is non-composite 16-byte and the target supports at least one composite
16-byte mode.
The inner loop is because we don't have a complex_float128_type_node macro,
so it needs to be found by iteration or hardcoding which entry it is
(it iterates over those 6 entries for complex _Float{32,64,128}{,x}).
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-25 19:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-24 19:34 [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194] Jakub Jelinek
2022-01-24 22:14 ` Mark Wielaard
2022-01-24 22:26 ` Jakub Jelinek
2022-01-25 11:02 ` [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194] Jakub Jelinek
2022-01-25 19:24 ` Jason Merrill
2022-01-25 19:36 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).