https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106755
--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #3) > So yes there is aliasing violation as you do the store as vui128_t aka > "__vector unsigned __int128" (which has the same aliasing set) as "__int128" > but then do the load from it as vui32_t aka "__vector unsigned int vui32_t" > (which is the same aliasing set as int). Yes, I came to the same conclusion and sent Steve a patch offline that fixes the issue. > -Wstrict-aliasing=3 might warn about this case I can't remember exactly of > the levels of the options but the -Wstrict-aliasing warnings are always not > going to happen, sometimes it is easier to read the code. Ah, I didn't realize we could increase the warning level. Cool! It seems -Wstrict-aliasing=2 is enough to catch the problem: gcc -O3 -Wall -c -fmessage-length=0 -mcpu=power8 -mtune=power8 -Wstrict-aliasing=2 -m64 ../src/vec_bug6.c ../src/vec_bug6.c: In function ‘test_muludq’: ../src/vec_bug6.c:969:45: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 969 | k = (vui32_t) test_vec_muludq((vui128_t* )&l, (vui128_t)i, (vui128_t)j); ...
