| Message ID | Y383ZmQYu/NFCmpI@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | libstdc++: Workaround buggy printf on Solaris in to_chars/float128_c++23.cc test [PR107815] | expand |
On Thu, 24 Nov 2022 at 09:20, Jakub Jelinek wrote: > > Hi! > > As mentioned in the PR, Solaris apparently can handle right > printf ("%.0Lf\n", 1e+202L * __DBL_MAX__); > which prints 511 chars long number, but can't handle > printf ("%.0Lf\n", 1e+203L * __DBL_MAX__); > nor > printf ("%.0Lf\n", __LDBL_MAX__); > properly, instead of printing 512 chars long number for the former and > 4933 chars long number for the second, it handles them as > if user asked for "%.0Le\n" in those cases. > > The following patch disables the single problematic value that fails > in the test, and also fixes commented out debugging printouts. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK, thanks > > 2022-11-24 Jakub Jelinek <jakub@redhat.com> > > PR libstdc++/107815 > * testsuite/20_util/to_chars/float128_c++23.cc (test): Disable > __FLT128_MAX__ test on Solaris. Fix up commented out debugging > printouts. > > --- libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc.jj 2022-11-08 11:19:22.251768167 +0100 > +++ libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc 2022-11-23 17:02:22.380051796 +0100 > @@ -52,14 +52,17 @@ test(std::chars_format fmt = std::chars_ > std::numbers::inv_sqrt3_v<std::float128_t>, > std::numbers::egamma_v<std::float128_t>, > std::numbers::phi_v<std::float128_t>, > +// Solaris has non-conforming printf, see PR98384 and PR107815. > +#if !(defined(__sun__) && defined(__svr4__)) > std::numeric_limits<std::float128_t>::max() > +#endif > }; > char str1[10000], str2[10000]; > for (auto u : tests) > { > auto [ptr1, ec1] = std::to_chars(str1, str1 + sizeof(str1), u, fmt); > VERIFY( ec1 == std::errc() ); > -// std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; > +// std::cout << u << ' ' << std::string_view (str1, ptr1) << '\n'; > if (fmt == std::chars_format::fixed) > { > auto [ptr2, ec2] = std::to_chars(str2, str2 + (ptr1 - str1), u, fmt); > @@ -76,7 +79,7 @@ test(std::chars_format fmt = std::chars_ > > auto [ptr5, ec5] = std::to_chars(str1, str1 + sizeof(str1), u, fmt, 90); > VERIFY( ec5 == std::errc() ); > -// std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; > +// std::cout << u << ' ' << std::string_view (str1, ptr5) << '\n'; > v = 4.0f128; > auto [ptr6, ec6] = std::from_chars(str1, ptr5, v, > fmt == std::chars_format{} > > Jakub >
--- libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc.jj 2022-11-08 11:19:22.251768167 +0100 +++ libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc 2022-11-23 17:02:22.380051796 +0100 @@ -52,14 +52,17 @@ test(std::chars_format fmt = std::chars_ std::numbers::inv_sqrt3_v<std::float128_t>, std::numbers::egamma_v<std::float128_t>, std::numbers::phi_v<std::float128_t>, +// Solaris has non-conforming printf, see PR98384 and PR107815. +#if !(defined(__sun__) && defined(__svr4__)) std::numeric_limits<std::float128_t>::max() +#endif }; char str1[10000], str2[10000]; for (auto u : tests) { auto [ptr1, ec1] = std::to_chars(str1, str1 + sizeof(str1), u, fmt); VERIFY( ec1 == std::errc() ); -// std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; +// std::cout << u << ' ' << std::string_view (str1, ptr1) << '\n'; if (fmt == std::chars_format::fixed) { auto [ptr2, ec2] = std::to_chars(str2, str2 + (ptr1 - str1), u, fmt); @@ -76,7 +79,7 @@ test(std::chars_format fmt = std::chars_ auto [ptr5, ec5] = std::to_chars(str1, str1 + sizeof(str1), u, fmt, 90); VERIFY( ec5 == std::errc() ); -// std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; +// std::cout << u << ' ' << std::string_view (str1, ptr5) << '\n'; v = 4.0f128; auto [ptr6, ec6] = std::from_chars(str1, ptr5, v, fmt == std::chars_format{}
Hi! As mentioned in the PR, Solaris apparently can handle right printf ("%.0Lf\n", 1e+202L * __DBL_MAX__); which prints 511 chars long number, but can't handle printf ("%.0Lf\n", 1e+203L * __DBL_MAX__); nor printf ("%.0Lf\n", __LDBL_MAX__); properly, instead of printing 512 chars long number for the former and 4933 chars long number for the second, it handles them as if user asked for "%.0Le\n" in those cases. The following patch disables the single problematic value that fails in the test, and also fixes commented out debugging printouts. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-11-24 Jakub Jelinek <jakub@redhat.com> PR libstdc++/107815 * testsuite/20_util/to_chars/float128_c++23.cc (test): Disable __FLT128_MAX__ test on Solaris. Fix up commented out debugging printouts. Jakub