[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[pbristow at hetp dot u-net.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122

--- Comment #21 from Paul A. Bristow  ---
I also note that 

 https://en.cppreference.com/w/cpp/io/manip/fixed
Notes
Hexadecimal floating-point formatting ignores the stream precision
specification,
as required by the specification of std::num_put::do_put.
  https://en.cppreference.com/w/cpp/locale/num_put/put
Additionally, if floatfield != (ios_base::fixed | ios_base::scientific),
then (since C++11) precision modifier is added, set to str.precision()

"When formatting a floating point value as hexfloat (i.e., when floatfield ==
(std::ios_base::fixed | std::ios_base::scientific)), the stream's precision is
not used; instead, the number is always printed with enough precision to
exactly represent the value." (since C++11)

but this is not what MSVC currently 16.7.0.Preview 3 is implementing as noted

https://developercommunity.visualstudio.com/content/problem/520472/hexfloat-stream-output-does-not-ignore-precision-a.html

*It would be extremely unfortunate if various compilers implemented this
differently.*

I see no case for precision to change the output from std::hexfloat because it
specifies a *decimal* precision, not a hexadecimal one.  std::hexfloat output
should always be enough precision to *exactly represent the value*, however
large.

It would be nice if std::showpoint could also respect output of trailing zeros,
so that the default std::showpoint  output displays neat columns, and that
std::noshowpoint made output with minimum size (for example, minimizing
serialized data).

(In passing, I note that std::scientific always includes (often many) trailing
zeros, ignoring showpoint.  Changing this would be logical but a breaking
change.)

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[pbristow at hetp dot u-net.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122

Paul A. Bristow  changed:

   What|Removed |Added

 CC||pbristow at hetp dot u-net.com

--- Comment #18 from Paul A. Bristow  ---
Working on test for Boost.Multiprecision UDTs, I have just stumbled on this,
expecting loopback to 'just work' as it does on Clang libc++ and MSVC.

LWG 2381 is still (currently open) and seems to have stalled?

Is there any way to get this resolved for GCC libstd++?

[Bug middle-end/50060] intrinsics not folded by the middle-end

[pbristow at hetp dot u-net.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50060

--- Comment #11 from Paul A. Bristow  ---
Thanks for all this, which looks helpful, but I am not able to use unreleased
compiler versions, so meanwhile I am working to use a workaround (to allow me
to see what other pitfalls lie ahead for the novice ;-).  FWIW my proof of
concept is 

// Version that returns both mantissa and exponent as a tuple.
// Proof of concept only, ignoring sign, overflow, denorm, infinite and NaNs.
constexpr std::tuple frexp(float f)
{
  int e = 0;

  if (f >= 1.f)
  {
f /= 2 ;
e++;
  }
  else if (f <= 0.1f)
  {
f *= 2;
e--;
  }
  return  std::make_tuple(f, e);
 }

allowing

constexpr std::tuple ee = frexp(1.f);

(I can confirm by checking that debugging will not step into the function, and
also I can assign the tuple or the elements to a constexpr variable.)

Of course, this isn't a 'drop-in' for std::frexp, nor templated on other
floating-point types, like Boost.Multiprecision types, but it will help for
now.

I hope that this can be resolved somehow eventually, though I fear the pointer
update will always be a nono for constexpr, preventing a truely 'drop-in'
solution thus preventing any function that uses frexp from being constexpr.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[pbristow at hetp dot u-net.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50060

Paul A. Bristow  changed:

   What|Removed |Added

 CC||pbristow at hetp dot u-net.com

--- Comment #6 from Paul A. Bristow  ---
This is a serious 'fault' that prevents making constexpr and functions that use
frexp, even though the mantissa and exponent are definitely constant.

This prevents using constexpr in Boost.Math functions and distributions,
Boost.Multiprecision and Proposed Boost.Fixed-Point.

Suggestions on workaround(s)?

Two separate constexpr functions for mantissa and exponent?

One function that 'returns' both as a tuple/pair?

Either are a major nuisance to replace frexp.

(Perhaps a single function to 'return' both doesn't such a good idea now?)

[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128

[pbristow at hetp dot u-net.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622

Paul A. Bristow pbristow at hetp dot u-net.com changed:

   What|Removed |Added

 CC||pbristow at hetp dot u-net.com

--- Comment #12 from Paul A. Bristow pbristow at hetp dot u-net.com ---
This still exists at 4.8.2 and is a *showstopper* for running the Boost.Math
library at all the available precisions, up to 128-bit precision where
available.

typeid(type).name() fails with:

undefined reference to `typeinfo for __float128'

We can check that the library seems to work OK by ugly hacking of error
handling and a few examples of test code (out of the hundreds of tests), but we
absolutely need this before it can be fully tested at 128-bit precision and
released.

Getting this library to pass is part of a demonstration of the proposed C++ and
C library additions by Christopher Kormanyos and John Maddock

Floating-Point Typedefs Having Specified Widths - N3626

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1703.pdf

Everything is working to provide full C++ 128-bit floating-point - apart from
this :-( 

So we are very keen to have a fix.