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.
