| Summary: | [3.4 only] vector varargs failure passing from altivec to non-altivec code for -m32 | ||
|---|---|---|---|
| Product: | gcc | Reporter: | janis187 |
| Component: | target | Assignee: | Alan Modra <amodra> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, marcus |
| Priority: | P2 | Keywords: | ABI, wrong-code |
| Version: | 3.4.0 | ||
| Target Milestone: | 3.4.1 | ||
| Host: | Target: | powerpc64-linux powerpc-linux | |
| Build: | Known to work: | 4.0.0 | |
| Known to fail: | Last reconfirmed: | 2004-04-27 09:18:24 | |
| Bug Depends on: | 15191 | ||
| Bug Blocks: | |||
| Attachments: | test case: two source files plus Makefile | ||
Created attachment 6154 [details]
test case: two source files plus Makefile
Confirmed. -m32 vector varargs looks badly broken. prototype patch at http://gcc.gnu.org/ml/gcc/2004-04/msg01316.html Fixed on mainline and hammer-3_3-branch. Patches listed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15191 Fixed |
It should be possible to write a library function that accepts vector arguments in a variable-length argument list, with that function compiled with -mno-altivec, the caller compiled with -maltivec, and both using the same Altivec ABI. With mainline this works for -m64 but not with -m32. The hammer-3.3 branch has the same problem; I haven't tried it for other branches but assume that 3.4 has does the same thing. The tarball includes two source files plus a Makefile that will build them in different combinations. The specific problem described here is demonstrated by the following, using a biarch powerpc64-linux compiler from mainline sources. Results for this test are not affected by patches from Alan Modra on April 23 or from Fariborz Jahanian on April 21. dufur% $GCC -m32 -maltivec -mabi=altivec -c -o bug_passer.o bug_passer.c dufur% $GCC -m32 -mno-altivec -mabi=altivec -c -o bug_passee.o bug_passee.c dufur% $GCC -m32 bug_passer.o bug_passee.o dufur% a.out Aborted If other failing combinations generated by the Makefile are not supported then they should be documented as not expected to work.