Bug 13992 - Apparent vrsave problem with complex Altivec code and -O2
Summary: Apparent vrsave problem with complex Altivec code and -O2
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: wrong-code
Depends on:
Reported: 2004-02-03 08:25 UTC by Timothy J. Wood
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: powerpc-apple-darwin7.2.0
Target: powerpc-apple-darwin7.2.0
Build: powerpc-apple-darwin7.2.0
Known to work:
Known to fail:
Last reconfirmed:

test case source file (2.21 KB, text/plain)
2004-02-03 08:26 UTC, Timothy J. Wood

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy J. Wood 2004-02-03 08:25:03 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 
-o iterator_10

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.
Comment 1 Timothy J. Wood 2004-02-03 08:26:14 UTC
Created attachment 5657 [details]
test case source file
Comment 2 Andrew Pinski 2004-02-03 08:40:32 UTC
You are violating aliasing rules.
Either use -fno-strict-aliasing or use unions instead of casting.
Comment 3 Timothy J. Wood 2004-02-04 08:00:03 UTC
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;

compiled with:

$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.

Comment 4 Andrew Pinski 2005-06-05 08:38:56 UTC
Reopening to ...
Comment 5 Andrew Pinski 2005-06-05 08:39:14 UTC
Mark as a dup of bug 21920.

*** This bug has been marked as a duplicate of 21920 ***