On Thu, May 15, 2025 at 7:46 PM Rainer Orth <r...@cebitec.uni-bielefeld.de>
wrote:

> Hi Jonathan,
>
> > On Thu, 15 May 2025 at 15:02, Rainer Orth <r...@cebitec.uni-bielefeld.de>
> wrote:
> >>
> >> Hi Jonathan,
> >>
> >> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
> >> >> > sparc-sun-solaris2.11:
> >> >> >
> >> >> > In file included from
> >> >> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format.cc:29:
> >> >> >
> /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/format:
> >> >> > In member function ‘typename std::basic_format_context<_Out,
> >> >> > _CharT>::iterator std::formatter<__float128,
> >> >> > _CharT>::format(__float128, std::basic_format_context<_Out,
> _CharT>&)
> >> >> > const’:
> >> >> >
> /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/format:2994:41:
> >> >> > error: ‘__flt128_t’ is not a member of ‘std::__format’; did you
> mean
> >> >> > ‘__bflt16_t’? [-Wtemplate-body]
> >> >> > 2994 |         { return _M_f.format((__format::__flt128_t)__u,
> __fc); }
> >> >> >      |                                         ^~~~~~~~~~
> >> >> >      |                                         __bflt16_t
> >> >> >
> >> >> > and one more instance.
> >> >>
> >> >> And on x86_64-darwin too.
> >> >
> >> > Tomasz, should this be:
> >> >
> >> > --- a/libstdc++-v3/include/std/format
> >> > +++ b/libstdc++-v3/include/std/format
> >> > @@ -2973,7 +2973,7 @@ namespace __format
> >> >     };
> >> > #endif
> >> >
> >> > -#if defined(__SIZEOF_FLOAT128__) && _GLIBCXX_FORMAT_F128 != 1
> >> > +#if defined(__SIZEOF_FLOAT128__) && _GLIBCXX_FORMAT_F128 > 1
> >> >   // Reuse __formatter_fp<C>::format<__format::__flt128_t, Out> for
> __float128.
> >> >   // This formatter is not declared if
> >> > _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT is true,
> >> >   // as __float128 when present is same type as __ieee128, which may
> be same as
> >> >
> >>
> >> with this patch applied, I could link libstdc++.so.  I'll run a full
> >> bootstrap later today.
> >
> >
> > Good to know, thanks. Tomasz already pushed that change as
> > r16-647-gd010a39b9e788a
> > so trunk should be OK now.
>
> it is on Solaris/i386, but sparc is broken in a different way now:
>
> /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/format:2999:23:
> error: static assertion failed: This specialization should not be used for
> long double
>  2999 |       static_assert( !is_same_v<__float128, long double>,
>       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/format:2999:23:
> note: ‘!(bool)std::is_same_v<long double, long double>’ evaluates to false
> /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/format:
> In instantiation of ‘struct std::formatter<long double, char>’:
> /var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/type_traits:3559:54:
>  required from ‘constexpr const bool
> std::is_default_constructible_v<std::formatter<long double, char> >’
>  3559 |   inline constexpr bool is_default_constructible_v =
> __is_constructible(_Tp);
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~
> [...]
>
> 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.

>
>         Rainer
>
> --
>
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>

Reply via email to