https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:481ba4fb5fce8257f5dbeb994dac2748c0237fa2
commit r14-9853-g481ba4fb5fce8257f5dbeb994dac2748c0237fa2
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #7 from Jakub Jelinek ---
Created attachment 57900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57900=edit
gcc14-pr114623.patch
Anyway, here is an untested patch to use soft-fp implementation for sqrtq for
the positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #6 from Jakub Jelinek ---
(In reply to g.peterhoff from comment #4)
> That is precisely the design error of C/C++/etc. There should be no
> float/double/long double/__float128/etc, but *only* floatN_t.
If you don't want to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #4 from g.peterh...@t-online.de ---
That is precisely the design error of C/C++/etc. There should be no
float/double/long double/__float128/etc, but *only* floatN_t. Then there
wouldn't be these discrepancies (if necessary you have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800#c4
Basically libquadmath should be using sqrt128f if it exist for sqrtq instead of
doing a version itself ... But libquadmath is normally only used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #2 from g.peterh...@t-online.de ---
#include
#include
#include
#include
#include
#include
#include
void print_hex(const std::float128_t value)
{
std::array
buffer{};
const std::to_chars_result
