GCC Bugzilla – Bug 13992
Apparent vrsave problem with complex Altivec code and -O2
Last modified: 2005-07-23 22:49:57 UTC
Sorry for the slightly large test case, but due to the nature of the (apparent) bug, I haven't been able
to make it significantly smaller.
../gcc/configure --prefix=/Users/bungi/Source/GNU/gcc/gcc-3.4/install --enable-
Building the attached test case with:
$PREFIX/bin/g++ -O2 -g -Wall -fno-exceptions -maltivec -force_cpusubtype_ALL iterator_10.cpp
When run, the output will have the line:
vBuckets: (0x7fffdead, 0x7fffdead, 0x7fffdead, 0x7fffdead)
implying to me that the vrsave register isn't getting stored correctly, or maybe some bad stack math
is happening. Making the test case smaller (removing the other logging or some of the vector
operations) makes the 0x7fffdead disappear.
Created attachment 5657 [details]
test case source file
You are violating aliasing rules.
Either use -fno-strict-aliasing or use unions instead of casting.
Hrm. I thought of that, but was misled by the fact that adding -Wstrict-aliasing didn't report any
warnings. I'm probably misunderstanding what this warning does (certainly looking at the only test
case for it I could find (gcc/testsuite/gcc.dg/alias-1.c) yields warnings that don't make sense.
Anyway, I'll try your suggestion, but I'd also think that if the -W flag is going to have a name of
'strict-aliasing' then it would be less confusing the more bad constructs it could detect.
As an example:
int x(float *f)
return *(int *)f;
$PREFIX/bin/g++ -O2 -Wall -fstrict-aliasing -Wstrict-aliasing -c foo.cpp
yields no warnings. Maybe I need to go read the language laws on aliasing more closely, but I
thought this was a classic example.
Reopening to ...
Mark as a dup of bug 21920.
*** This bug has been marked as a duplicate of 21920 ***