https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #8 from Alexander Monakov ---
But that's the point of many warnings, isn't it? To help the user understand
what's wrong when the code is bad? And bogus warnings just confuse more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #7 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #6)
> Andrew, surely the bogus -Wuninitialized warning is a GCC bug here?
No. It is just exposing the undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #5 from Vitaly Chikunov ---
I experimented with `_mm256_extract_epi16` too and loop liek this worked too:
```
# pragma GCC unroll 16
for (size_t i = 0; i < 16; i++) {
printf(" %04x", _mm256_extract_epi16(tmp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #4 from Vitaly Chikunov ---
Andrew, thanks for the quick answer and example! I wish that warning was a bit
more enlightening, and in the first case it is not quietly compiles producing
incorrect code (which is only found by testing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #3 from Andrew Pinski ---
The other fix is to use _mm256_extract_epi16.
E.g.
inline unsigned short extract_epi16(__m256i v, int pos) {
switch(pos){
case 0: return _mm256_extract_epi16(v, 0);
case 1: return _mm25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #2 from Andrew Pinski ---
The easiest way to fix this is to use GNU-C vectors like:
for (size_t i = 0; i < 16; i++) {
typedef __attribute__((vector_size(sizeof(__m256i)) )) uint16_t
myvector_t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
