[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #32 from Jonathan Wakely --- Hmm, yes. Well I think we can at least make std::is_integral<__int128> true, which will remove once source of surprises for users.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #31 from joseph at codesourcery dot com --- It can be an extended integer type in C2x, but then stdint.h would be required to have int128_t / uint128_t / int_least128_t / uint_least128_t typedefs, and integer constant suffixes would be needed for the corresponding macros INT128_C / UINT128_C (and the other stdint.h macros for the types would need to be defined as well), and printf/scanf support would be required as well.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #30 from Jonathan Wakely --- (In reply to John Maddock from comment #26) > (In reply to jos...@codesourcery.com from comment #25) > > On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote: > > > > > While we're opening cans of worms intmax_t should clearly be > > > __int128... > > > just saying! > > > > Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I > > call a sui generis extended type, not an integer type. > > So it's an integer that's not an integer? I'm sorry but that's just > nonesense. Of course I realise that ABI issues may trump other concerns, > but please call a spade a spade! In any case this is a glibc issue and > we're off topic here... With changes to the definition of intmax_t in C2x (and C++23) that problem is gone. __int128 can be an extended integer type, and intmax_t doesn't need to change, so there's no ABI problem. Order is restored to the galaxy.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Jonathan Wakely --- (In reply to Marc Glisse from comment #22) > __float128 is still missing a specialization of numeric_limits. We're still missing that, but I created PR libstdc++/104772 for it. I don't think we need full and I/O support for __float128, so let's close this one.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #28 from Andrew Pinski --- I suspect this has now been fixed with the additional of full _Float128 support in the C++ front-end and the library work.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-04 Summary|no C++ typeinfo for |Incomplete C++ library |__float128 |support for __float128 Ever confirmed|0 |1 --- Comment #27 from Marc Glisse glisse at gcc dot gnu.org --- Renaming since typeinfo is in gcc-5.
