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.
>
> Rainer
>
> --
>
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
