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
