diff mbox series

[02/52] d: Replace use of LONG_DOUBLE_TYPE_SIZE

Message ID cb19f08ef21c365a54d5533ae8d1509409102637.1717134752.git.linkw@linux.ibm.com
State New
Headers show
Series Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook | expand

Commit Message

Kewen.Lin June 3, 2024, 3 a.m. UTC
Joseph pointed out "floating types should have their mode,
not a poorly defined precision value" in the discussion[1],
as he and Richi suggested, the existing macros
{FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
hook mode_for_floating_type.  To be prepared for that, this
patch is to replace use of LONG_DOUBLE_TYPE_SIZE in d with
TYPE_PRECISION of long_double_type_node.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html

gcc/d/ChangeLog:

	* d-target.cc (Target::_init): Use TYPE_PRECISION of
	long_double_type_node to replace LONG_DOUBLE_TYPE_SIZE.
---
 gcc/d/d-target.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Iain Buclaw June 3, 2024, 8:40 a.m. UTC | #1
Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am:
> Joseph pointed out "floating types should have their mode,
> not a poorly defined precision value" in the discussion[1],
> as he and Richi suggested, the existing macros
> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
> hook mode_for_floating_type.  To be prepared for that, this
> patch is to replace use of LONG_DOUBLE_TYPE_SIZE in d with
> TYPE_PRECISION of long_double_type_node.
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
> 

Thanks, one question though: Is TYPE_PRECISION really equivalent to
LONG_DOUBLE_TYPE_SIZE?

Unless LONG_DOUBLE_TYPE_SIZE was poorly named to begin with, I'd assume
the answer to be "no".

i.e: TYPE_PRECISION = 80, but LONG_DOUBLE_TYPE_SIZE = 96 or 128.

Iain.
Kewen.Lin June 3, 2024, 8:57 a.m. UTC | #2
Hi Iain,

on 2024/6/3 16:40, Iain Buclaw wrote:
> Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am:
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as he and Richi suggested, the existing macros
>> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
>> hook mode_for_floating_type.  To be prepared for that, this
>> patch is to replace use of LONG_DOUBLE_TYPE_SIZE in d with
>> TYPE_PRECISION of long_double_type_node.
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
>>
> 
> Thanks, one question though: Is TYPE_PRECISION really equivalent to
> LONG_DOUBLE_TYPE_SIZE?

Yes, it's guaranteed by the code in build_common_tree_nodes:

  long_double_type_node = make_node (REAL_TYPE);
  TYPE_PRECISION (long_double_type_node) = LONG_DOUBLE_TYPE_SIZE;
  layout_type (long_double_type_node);

, the macro LONG_DOUBLE_TYPE_SIZE is assigned to TYPE_PRECISION of
long_double_type_node, layout_type will only pick up one mode as
the given precision and won't change it.

> 
> Unless LONG_DOUBLE_TYPE_SIZE was poorly named to begin with, I'd assume
> the answer to be "no".

I'm afraid it's poorly named before.

> 
> i.e: TYPE_PRECISION = 80, but LONG_DOUBLE_TYPE_SIZE = 96 or 128.

From what I interpreted from the code, it should never happen.

BR,
Kewen
Iain Buclaw June 3, 2024, 2:39 p.m. UTC | #3
Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am:
> Hi Iain,
> 
> on 2024/6/3 16:40, Iain Buclaw wrote:
>> Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am:
>>> Joseph pointed out "floating types should have their mode,
>>> not a poorly defined precision value" in the discussion[1],
>>> as he and Richi suggested, the existing macros
>>> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
>>> hook mode_for_floating_type.  To be prepared for that, this
>>> patch is to replace use of LONG_DOUBLE_TYPE_SIZE in d with
>>> TYPE_PRECISION of long_double_type_node.
>>>
>>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
>>>
>> 
>> Thanks, one question though: Is TYPE_PRECISION really equivalent to
>> LONG_DOUBLE_TYPE_SIZE?
> 
> Yes, it's guaranteed by the code in build_common_tree_nodes:
> 
>   long_double_type_node = make_node (REAL_TYPE);
>   TYPE_PRECISION (long_double_type_node) = LONG_DOUBLE_TYPE_SIZE;
>   layout_type (long_double_type_node);
> 
> , the macro LONG_DOUBLE_TYPE_SIZE is assigned to TYPE_PRECISION of
> long_double_type_node, layout_type will only pick up one mode as
> the given precision and won't change it.
> 
>> 
>> Unless LONG_DOUBLE_TYPE_SIZE was poorly named to begin with, I'd assume
>> the answer to be "no".
> 
> I'm afraid it's poorly named before.
> 

Thanks for confirming Kewen.

I suspect then that this code is incorrectly using this macro, and it
should instead be using:

int_size_in_bytes(long_double_type_node)

as any padding should be considered as part of the overall type size for
the purpose that this field serves in the D part of the front-end.

Are you able to update the patch this way instead? Otherwise I'm happy
to push the change instead.

Thanks again,
Iain.
diff mbox series

Patch

diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc
index 127b9d7ce7c..079731f68ab 100644
--- a/gcc/d/d-target.cc
+++ b/gcc/d/d-target.cc
@@ -163,7 +163,8 @@  Target::_init (const Param &)
   this->c.intsize = (INT_TYPE_SIZE / BITS_PER_UNIT);
   this->c.longsize = (LONG_TYPE_SIZE / BITS_PER_UNIT);
   this->c.long_longsize = (LONG_LONG_TYPE_SIZE / BITS_PER_UNIT);
-  this->c.long_doublesize = (LONG_DOUBLE_TYPE_SIZE / BITS_PER_UNIT);
+  this->c.long_doublesize
+    = (TYPE_PRECISION (long_double_type_node) / BITS_PER_UNIT);
   this->c.wchar_tsize = (WCHAR_TYPE_SIZE / BITS_PER_UNIT);
 
   this->c.bitFieldStyle = targetm.ms_bitfield_layout_p (unknown_type_node)