Message ID | cb19f08ef21c365a54d5533ae8d1509409102637.1717134752.git.linkw@linux.ibm.com |
---|---|
State | New |
Headers | show |
Series | Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook | expand |
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.
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
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 --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)