| Message ID | 579db142-fd34-0777-99ab-12052e03dd44@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Excerpts from Kewen.Lin's message of Juni 4, 2024 5:17 am: > Hi Iain, > > on 2024/6/3 22:39, Iain Buclaw wrote: >> 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. > > Got it, thanks for the explanation and suggestion. > >> >> Are you able to update the patch this way instead? Otherwise I'm happy >> to push the change instead. > > Sure, updated as below: > Thanks! This is OK to apply any time. Iain.
Hi Iain, on 2024/6/4 19:35, Iain Buclaw wrote: > Excerpts from Kewen.Lin's message of Juni 4, 2024 5:17 am: >> Hi Iain, >> >> on 2024/6/3 22:39, Iain Buclaw wrote: >>> 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. >> >> Got it, thanks for the explanation and suggestion. >> >>> >>> Are you able to update the patch this way instead? Otherwise I'm happy >>> to push the change instead. >> >> Sure, updated as below: >> > > Thanks! > > This is OK to apply any time. Pushed as r15-1032, thanks! BR, Kewen
diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc index 127b9d7ce7c..dd46e535891 100644 --- a/gcc/d/d-target.cc +++ b/gcc/d/d-target.cc @@ -163,7 +163,7 @@ 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 = int_size_in_bytes (long_double_type_node); this->c.wchar_tsize = (WCHAR_TYPE_SIZE / BITS_PER_UNIT); this->c.bitFieldStyle = targetm.ms_bitfield_layout_p (unknown_type_node)