On Thu, May 15, 2025 at 9:59 PM Tomasz Kaminski <tkami...@redhat.com> wrote:
>
>
> On Thu, May 15, 2025 at 9:45 PM Rainer Orth <r...@cebitec.uni-bielefeld.de>
> wrote:
>
>> Hi Tomasz,
>>
>> >> I've a local patch in tree to support __float128 on SPARC, so I'll try
>> >> with an unmodified tree first. However, 2 days ago I could bootstrap
>> >> with that included just fine.
>> >>
>> > Is __float128 a distinct type from long double, in case when both are
>> > 128bit?
>> > I have assumed that this would be the case, and this specialization is
>> > meant to avoid generating separate formatting code for both of them.
>>
>> I'm using
>>
>> /* Create builtin type for __float128. */
>>
>> static void
>> sparc_float128_init_builtins (void)
>> {
>> /* With 128-bit long double, the __float128 type is a synonym for
>> "long double". */
>> lang_hooks.types.register_builtin_type (long_double_type_node,
>> "__float128");
>> }
>>
>> I guess I should file a PR for this, attaching the current patch, to
>> discuss the remaining issues (fetestexcept failures in the testsuite, on
>> both Solaris/sparc and Linux/sparc64).
>>
> I am not aware of architectures where the additional specialization for
> __float128
> would be useful, so if my patch of changing _GLIBCXX_FORMAT_F128 > 1 to
> _GLIBCXX_FORMAT_F128 == 2
> addressed your build, I can submit it.
>
This specialization would be used for x86 with -m32 -mlong-double-128,
where __float128
is distinct type from long double, that is IEE 128:
https://godbolt.org/z/rWhrGYcdc
However, I do not know if we support this configuration.
>
>> Rainer
>>
>> --
>>
>> -----------------------------------------------------------------------------
>> Rainer Orth, Center for Biotechnology, Bielefeld University
>>
>>
