https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958
--- Comment #6 from Matthias Kretz (Vir) ---
The last commit introduced a regression on i686 where __builtin_shufflevector
was producing MMX vectors (which can mess up the FPU). Untested patch which
resolves the issue:
libstdc++-v3/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
--- Comment #12 from Matthias Kretz (Vir) ---
Fixed powerpc test failure on all branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114966
--- Comment #4 from Matthias Kretz (Vir) ---
I'm fairly sure it's not the same source anymore. I'll try to understand where
it goes wrong in the library, because the vector_t{0, data[0], data[1],
data[2]} expression is still optimized as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114966
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958
--- Comment #3 from Matthias Kretz (Vir) ---
Hmm, it actually fails on Clang because Clang requires the vector width of both
arguments to be equal.
But yes, I guess I should make __vec_shuffle friendlier to non-GCC compilers.
I'm not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
--- Comment #7 from Matthias Kretz (Vir) ---
I suspect resolving this is only one part of it. But I'm happy to be proven
wrong. :)
I opened PR114958 to track the simd implementation change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958
Bug ID: 114958
Summary: use __builtin_shufflevector for
std::experimental::simd split and concat (at least the
common cases) to enable better optimizations
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
--- Comment #5 from Matthias Kretz (Vir) ---
https://godbolt.org/z/P6cfbjT9f
#include
typedef uint64_t T;
typedef T V [[gnu::vector_size(32)]];
typedef struct simd4 {
V data;
} simd4;
typedef struct simd1 {
T data;
} simd1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
--- Comment #3 from Matthias Kretz (Vir) ---
The stdx::simd implementation in this area is old and mainly tuned to be
correct. I can rewrite the split and concat implementation to use
__builtin_shufflevector (which wasn't available in GCC at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #2 from Matthias Kretz (Vir) ---
Fixed in master, still need to backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
Bug ID: 114803
Summary: simd conversion to [[gnu::vector_size(N)]] type hits
invalid code in experimental/bits/simd_builtin.h
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
--- Comment #2 from Matthias Kretz (Vir) ---
Resolved on master. Still need to backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114417
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114417
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #15 from Matthias Kretz (Vir) ---
So it seems that if at least one of the vector builtins involved in the
expression is 512 bits GCC needs to locally increase prefer-vector-width to
512? Or, more generally:
prefer-vector-width =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Bug ID: 114783
Summary: [14 Regression] Equality compares of vector builtins
spill one operand to the stack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #13 from Matthias Kretz (Vir) ---
Should I open a new PR for the remaining ((u)int64, 16) <-> (float, 16)
conversions?
https://godbolt.org/z/x3xPMYKj3
Note that __builtin_convertvector produces the code we want.
template
using V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
Bug ID: 114750
Summary: converting load/store of simd fails compilation on ARM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Bug ID: 114742
Summary: invalid use of '__ieee128' in
and
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #7 from Matthias Kretz (Vir) ---
looks good to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #24 from Matthias Kretz (Vir) ---
(In reply to g.peterhoff from comment #23)
> * How do you create the benchmarks?
https://github.com/mattkretz/simd-benchmarks
Look at hypot3.cpp :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91861
--- Comment #4 from Matthias Kretz (Vir) ---
> But NLT_UQ does not exist for non-VEX encoded
Right, one needs to compare integers and check for NaN. Like noted in the
description. Also implemented in the std::experimental::simd overloads:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #22 from Matthias Kretz (Vir) ---
I took your hypot3_scale and reduced latency and throughput. I don't think the
sqrtmax/sqrtmin limits are correct (sqrtmax² * 3 -> infinity).
TYPE Latency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #20 from Matthias Kretz (Vir) ---
Thanks, I'd be very happy if such a relatively clear implementation could make
it!
> branchfree code is always better.
Don't say it like that. Smart branching, making use of how static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #17 from Matthias Kretz (Vir) ---
hypotf(a, b) is implemented using double precision and hypot(a, b) uses 80-bit
long double on i386 and x86_64 hypot does what you describe, right?
std::experimental::simd benchmarks of hypot(a, b),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #15 from Matthias Kretz (Vir) ---
Your implementation still needs to solve:
1. Loss of precision because of division & subsequent scaling by max. Users
comparing std::hypot(x, y, z) against a simple std::sqrt(x * x + y * y + z * z)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #5 from Matthias Kretz (Vir) ---
OK, I can follow that reasoning. It's still a breaking change for everyone that
was using int up to this point. I guess the argument is that using int was
wrong in the first place and it just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302
Matthias Kretz (Vir) changed:
What|Removed |Added
Target Milestone|--- |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302
Bug ID: 111302
Summary: aligned std::experimental::simd loads and stores are
not constant expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110583
Bug ID: 110583
Summary: [x86] missed optimizations in vector concatenation
patterns
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054
--- Comment #3 from Matthias Kretz (Vir) ---
Fixed on master. Will backport later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #7 from Matthias Kretz (Vir) ---
Yes, I still need to backport because the new test is also present on the
branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #5 from Matthias Kretz (Vir) ---
The issue was an incorrect condition for SIMD support, which wanted to say only
single-precision float SIMD is available. It did that by excluding double,
failing to also exclude long double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
Matthias Kretz (Vir) changed:
What|Removed |Added
Last reconfirmed||2023-05-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054
Bug ID: 110054
Summary: stdx::simd masked store should not use non-temporal
store instruction
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Bug ID: 109964
Summary: auto-vectorization of shift ignores integral
promotions
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #8 from Matthias Kretz (Vir) ---
Created attachment 55150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55150=edit
proposed solution
This patch allows unsigned intrinsic types and calls vec_cntm correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #7 from Matthias Kretz (Vir) ---
> You should backport to N-1 first [...]
That was my intent. My workflow had not yet adapted to the existence of
releases/gcc-13. Fixed.
> never use -mpower9-vector and friends
I use -mpcu in my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #4 from Matthias Kretz (Vir) ---
With -mcpu=power10 I see the issue. The problem has been there all the time and
only surfaced with this test. (It should also have shown on `make check-simd`
in libstdc++.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #3 from Matthias Kretz (Vir) ---
I need help on how to reproduce this error. Your first lines say that the test
was compiled with `-maltivec -mpower9-vector -O2 -Wno-psabi` but that it only
happens with POWER 10? Do I need different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #2 from Matthias Kretz (Vir) ---
Yes, I stopped my backporting efforts when I became aware that it's failing on
ARM. I'll get to PPC ASAP and then continue with the backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #7 from Matthias Kretz (Vir) ---
Created attachment 55146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55146=edit
patch that resolves it for me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #5 from Matthias Kretz (Vir) ---
Th(In reply to Christophe Lyon from comment #4)
> The new testcase fails on arm and aarch64.
trunk or the backport? I tested trunk on gcc185. Will check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Target Milestone|13.2|12.4
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Matthias Kretz (Vir) changed:
What|Removed |Added
Last reconfirmed||2023-03-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Bug ID: 109261
Summary: std::experimental::simd is not usable in several
constant expressions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #6 from Matthias Kretz (Vir) ---
Most of the conversions are optimized perfectly now. Only the following
conversions are still missing for AVX-512:
https://godbolt.org/z/9afWbYod6
#include
template
using V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856
Matthias Kretz (Vir) changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #6 from Matthias Kretz (Vir) ---
This improves the situation. But according to tests of fixed_size_simd in a GNU
Radio prototype it still isn't enough. It seems like I need to always_inline
all non-cmath operations on fixed_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856
Bug ID: 108856
Summary: Increment and decrement on
std::experimental::where_expression should optimize
better
Product: gcc
Version: 13.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #3 from Matthias Kretz (Vir) ---
(In reply to Jakub Jelinek from comment #2)
> I bet by adding too many always_inline functions that call normal inlines
> that is what is bound to happen, one runs into inline growth limits. It is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
--- Comment #4 from Matthias Kretz (Vir) ---
I agree that compilation speed is a problem. However,
1. GCC's vector extensions are not sufficient (especially for use of AVX-512
masks)
2. I see 0.6s difference between calling `g++ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106520
Bug ID: 106520
Summary: 2+ index expressions in build_op_subscript are
incorrectly interpreted as comma expression
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
--- Comment #4 from Matthias Kretz (Vir) ---
I can certainly take a look, but so far my GCC internals experience ends with
the C++ front-end. This ICEs in the pass where front-end trees are transformed
into GIMPLE, right? So it would be a pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102219
Bug ID: 102219
Summary: fast-math inhibits fp contraction for a + b * a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100763
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100763
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #29 from Matthias Kretz (Vir) ---
(In reply to Vincent Lefèvre from comment #28)
> (In reply to Matthias Kretz (Vir) from comment #27)
> > Fair enough. But how can the compiler be certain that the developer realized
> > u and u % 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #27 from Matthias Kretz (Vir) ---
(In reply to Vincent Lefèvre from comment #26)
> But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the
> range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #25 from Matthias Kretz (Vir) ---
(In reply to Piotr Engelking from comment #24)
> It would be nice if the compiler noticed that rhs is always within
> 0..SHRT_MAX, so the comparison is not surprisingly affected by integer
>
81 matches
Mail list logo
