https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #29 from g.peterh...@t-online.de ---
(In reply to Jakub Jelinek from comment #28)
> As long as the scale is a power of two or 1.0 / power of two, I don't see
> why any version wouldn't be inaccurate.
Yes, but the constant scale_up is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #27 from g.peterh...@t-online.de ---
Hi Matthias,
thanks for your benchmark. I still have 2 questions:
1) Accuracy
The frexp/ldexp variant seems to be the most accurate; is that correct? Then
other constants would have to be used in
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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
Bug ID: 114623
Summary: sqrt
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #26 from g.peterh...@t-online.de ---
must of course be "... / scale".
How can I still edit posts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #25 from g.peterh...@t-online.de ---
Hi Matthias,
to get good results on average (all FP-types: (B)FP16..FP128,
scalar/vectorized(SIMD)/parallel/...) this algorithm seems to me (so far) to be
suitable:
template
inline constexpr Type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #23 from g.peterh...@t-online.de ---
Hello Matthias,
you've given me new ideas. I think we agree on implementing hypot3 using a
scaling factor. But the correct value is not yet implemented here either; do
you have a suggestion?
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #19 from g.peterh...@t-online.de ---
> So, no need to use frexp/ldexp, just comparisons of hi above against sqrt of
> (max finite / 3), in that case scale by multiplying all 3 args by some
> appropriate scale constant, and similarly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #13 from g.peterh...@t-online.de ---
Thanks for the suggestions:
template
constexpr _Tp __hypot3(_Tp __x, _Tp __y, _Tp __z) noexcept
{
if (std::isinf(__x) | std::isinf(__y) | std::isinf(__z))
[[__unlikely__]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
g.peterh...@t-online.de changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
g.peterh...@t-online.de changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
g.peterh...@t-online.de changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
g.peterh...@t-online.de changed:
What|Removed |Added
Resolution|MOVED |FIXED
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
--- Comment #3 from g.peterh...@t-online.de ---
Of course issubnormal is defined in math.h (in my case line 1088, gcc 13.2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
Bug ID: 114181
Summary: issubnormal is a macro
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
g.peterh...@t-online.de changed:
What|Removed |Added
CC||g.peterh...@t-online.de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #13 from g.peterh...@t-online.de ---
> The cppreference page is wrong.
But then *all* of your implementations for fmin/fmax (float, double, long
double, std::floatN_t) would be wrong, because they give exactly the results as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #7 from g.peterh...@t-online.de ---
I think there is a misunderstanding. The problem is that std::fmin/std::fmax
and quadmath fminq/fmaxq give different results when only *one* argument is
signaling_NaN.
The standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50597
g.peterh...@t-online.de changed:
What|Removed |Added
CC||g.peterh...@t-online.de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Bug ID: 114140
Summary: quadmath fminq/fmaxq with signaling_NaN not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114131
Bug ID: 114131
Summary: std::isinf(std::float128_t) generates superfluous
nan-checks
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Bug ID: 114018
Summary: std::nexttoward is not implemented for C++23-FP-Types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #7 from g.peterh...@t-online.de ---
Thank you. That was my question whether these two functions could be added.
At the moment I'm using boost.charconv https://github.com/cppalliance/charconv
https://develop.charconv.cpp.al (not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #5 from g.peterh...@t-online.de ---
??? I asked for std::from_chars/std::to_chars - which of course doesn't work:
https://godbolt.org/z/n34dTajoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
--- Comment #2 from g.peterh...@t-online.de ---
I'm currently fiddling around with a library for/with boost. I don't need this
kind of incompatibility.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #3 from g.peterh...@t-online.de ---
My problem is that I need from_chars/to_chars for __float128 also for older C++
standards that do not yet support _Float128/std::float128_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Bug ID: 113260
Summary: missing from_chars/to_chars for __float128
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
Bug ID: 113259
Summary: quadmath::nanq not support payload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109924
--- Comment #3 from g.peterh...@t-online.de ---
But in your documentation
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html it is stated that the
__builtin's would be available for all FP types.
For upcoming standards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109928
Bug ID: 109928
Summary: std::abs(long/long long) are not constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109924
Bug ID: 109924
Summary: missing __builtin_nanf16b
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #3 from g.peterh...@t-online.de ---
But these are different types (even if they are mathematically/behaviorally
equivalent)
std::is_same_v --> false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
Bug ID: 109884
Summary: __builtin_Xq returns _Float128 instead of __float128
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758
--- Comment #7 from g.peterh...@t-online.de ---
1) Can you please still submit a proposal to the STD/ISO committee so that abs
(besides copysign/signbit) ALWAYS works ?
2) What do you think about my proposal for a C++ interface quadmath.hpp ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758
--- Comment #5 from g.peterh...@t-online.de ---
>> Again, what do you mean by "quadmath"?
__float128 https://github.com/gcc-mirror/gcc/tree/master/libquadmath
This is not to be confused with C++23 std::float128_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758
--- Comment #3 from g.peterh...@t-online.de ---
>> libstdc++ doesn't depend on libquadmath and the __float128 support is there
>> very limited.
Yes, exactly. There should be nothing of quadmath in the std implementations of
C/C++. But in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758
Bug ID: 109758
Summary: quadmath abs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109378
g.peterh...@t-online.de changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109378
--- Comment #8 from g.peterh...@t-online.de ---
But I don't want and can't use a version of std::sqrt that requires compiler
specific flags/options/__builtins and injects internals of
std::sqrt/__builtin_sqrt into the calling context/function.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109378
--- Comment #4 from g.peterh...@t-online.de ---
Hm. Maybe we misunderstood each other or I don't understand. I don't want to
set -fno-math-errno or any other compiler-specific flag. My intention is that
__builtin_sqrt doesn't "contaminate" the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109378
--- Comment #2 from g.peterh...@t-online.de ---
But this is of no use if I want to compile something "normally" without
compiler specific options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109379
Bug ID: 109379
Summary: improve __builtin_fmal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109378
Bug ID: 109378
Summary: improve __builtin_sqrt
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #1 from g.peterh...@t-online.de ---
Ok in english
std::signbit(double) generates very inefficient code and thus cannot be
vectorized (https://godbolt.org/z/se6Ea8bo9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
Bug ID: 109029
Summary: std::signbit(double) generiert sehr ineffizienten code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
--- Comment #2 from g.peterh...@t-online.de ---
> X87 code generation is definitely not as optimized as other code really.
Ok
> Also fcmov is newish.
New?
fcmov was introduced with the PentiumPro (1995) - that's 27 years ago. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
Bug ID: 109028
Summary: fcmov will not be generated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
--- Comment #5 from g.peterh...@t-online.de ---
add test case (https://godbolt.org/z/q65cWKhWx)
void inc_builtin(array_t& arr)noexcept
{
auto load_cvt = [](const std::float16_t*const ptr) noexcept
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
Bug ID: 108902
Summary: Conversions std::float16_t<->float with FP16C are not
vectorized
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107458
Bug ID: 107458
Summary: std::fma generates slow scalar-call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
--- Comment #2 from g.peterh...@t-online.de ---
Another example. I want to convert an array to array.
There are basically 3 options:
- Copy
- Test (b2f64_default)
- optimized version (b2f64_manually)
gcc12.2 + gcctrunc
convertSIZE_copy only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
Bug ID: 107432
Summary: __builtin_convertvector generates inefficient code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283
--- Comment #2 from g.peterh...@t-online.de ---
That will be right. I had reported something similar many years ago - but it
was not fixed.
thx
Gero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283
Bug ID: 107283
Summary: conversions u/int64_t to float64/32_t are not
vectorized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281
Bug ID: 107281
Summary: comparisations with u/int64_t constants not generate
vector-result
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104695
--- Comment #2 from g.peterh...@t-online.de ---
Yes, that is very vaguely worded. However, the std functions or builtins must
always return the same values on the same platform.
quiet nan:
libquadmath::nanq != __builtin_nanf128
signaling nan:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104695
Bug ID: 104695
Summary: different bit patterns in __builtin_nans and
libquadmath::nanq
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100627
--- Comment #2 from g.peterh...@t-online.de ---
Hello,
i found a better solution here
https://stackoverflow.com/questions/41144668/how-to-efficiently-perform-double-int64-conversions-with-sse-avx
and ported to "normal" C++-code (no intrinsics)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100627
Bug ID: 100627
Summary: missing optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100171
Bug ID: 100171
Summary: autovectorizer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
--- Comment #2 from g.peterh...@t-online.de ---
That is not the problem. I only made using type = ... and type(x) in the ctor
calls so that I can test different types. You like to throw that out - has no
influence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
Bug ID: 99841
Summary: (temporary) refs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99228
--- Comment #5 from g.peterh...@t-online.de ---
Here is a better test case. https://godbolt.org/z/3Gq783
I've found:
sgn_complex
- always inefficient code, TYPE and SIZE do not matter, even with -Ofast or
-fast-math
for TYPE=double
SIZE=1
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99228
--- Comment #2 from g.peterh...@t-online.de ---
I only use the types of boost here. You can remove boost and use:
using float80_t = long double;
using float64_t = double;
using float32_t = float;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99228
Bug ID: 99228
Summary: blend/shuffle
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
66 matches
Mail list logo
