vector constants are allocated in reversed order when building the test program
for a PowerPC little-endian executable.
Test case code, altivec_test.c
--------------------------------------
#include <stdio.h>
#if __GNUC__ >= 3
#include <altivec.h>
#endif
int main(void)
{
#if __GNUC__ >= 3
vector signed char vsc = (vector signed char) {'f', 'e', 'd', 'c', 'b', 'a',
'9', '8', '7', '6', '5', '4', '3', '2', '1', '0'} ;
vector unsigned short vus = (vector unsigned short) {1, 2, 3, 4, 5, 6, 7,
8} ;
vector float vf = (vector float){1.0, 2.0, 3.0, 4.0};
#else
vector signed char vsc = (vector signed char) ('f', 'e', 'd', 'c', 'b', 'a',
'9', '8', '7', '6', '5', '4', '3', '2', '1', '0') ;
vector unsigned short vus = (vector unsigned short) (1, 2, 3, 4, 5, 6, 7,
8) ;
vector float vf = (vector float) (1.0, 2.0, 3.0, 4.0) ;
#endif
printf("vsc=(%vc)\n", (vector signed char)vsc) ;
printf("vus=(%vhu)\n", (vector unsigned short)vus) ;
printf("vf=(%vf)\n", vf) ;
return 0 ;
-----------------------------------------------
The command line used to compile the test:
powerpc-eabi-gcc -maltivec -mlittle -c -o altivec_test.oppc_le altivec_test.c
The "objdump -s altivec_test.oppc_le" generated information is:
altivec_test.oppc_le: file format elf32-little
Contents of section .text:
0000 60ff2194 a602087c 9c00e193 a4000190 `.!....|........
0010 780b3f7c 01000048 0000203d 30002939 x.?|...H.. =0.)9
0020 ce48007c 40000038 ce011f7c 40000038 .H.|@..8...|@..8
0030 ce001f7c 30000038 ce011f7c 0000203d ...|0..8...|.. =
0040 40002939 ce48007c 60000038 ce011f7c @.)9.H.|`..8...|
0050 60000038 ce001f7c 50000038 ce011f7c `..8...|P..8...|
0060 0000203d 50002939 ce48007c 80000038 .. =P.)9.H.|...8
0070 ce011f7c 80000038 ce001f7c 70000038 ...|...8...|p..8
0080 ce011f7c 08006039 30000038 ce001f7c ...|..`90..8...|
0090 08002139 ce59097c 0000203d 00006938 ..!9.Y.|.. =..i8
00a0 8231c64c 01000048 08006039 50000038 .1.L...H..`9P..8
00b0 ce001f7c 08002139 ce59097c 0000203d ...|..!9.Y.|.. =
00c0 0c006938 8231c64c 01000048 08006039 ..i8.1.L...H..`9
00d0 70000038 ce001f7c 08002139 ce59097c p..8...|..!9.Y.|
00e0 0000203d 18006938 8231c64c 01000048 .. =..i8.1.L...H
00f0 00000038 7803037c 00006181 04000b80 ...8x..|..a.....
0100 a603087c fcffeb83 785b617d 2000804e ...|....x[a} ..N
Contents of section .data:
Contents of section .rodata:
0000 7673633d 28257663 290a0000 7675733d vsc=(%vc)...vus=
0010 28257668 75290a00 76663d28 25766629 (%vhu)..vf=(%vf)
0020 0a000000 00000000 00000000 00000000 ................
0030 66656463 62613938 37363534 33323130 fedcba9876543210
0040 01000200 03000400 05000600 07000800 ................
0050 0000803f 00000040 00004040 00008040 [EMAIL PROTECTED]@@...@
Contents of section .comment:
0000 00474343 3a202847 4e552920 332e342e .GCC: (GNU) 3.4.
0010 3400 4.
Note, in the .rodata section, the compiler generates reversed order codes for
0030 0040 and 0050. Actually the codes are the same as big-endian.
It should generate code like this:
0030 30313233 34353637 38396162 63646566 0123456789abcdef
0040 08000700 06000500 04000300 02000100 ................
0050 00008040 00004040 00000040 0000803f [EMAIL PROTECTED]@@[EMAIL PROTECTED]
I can also find the compiler generates reversed order codes from the assembly
codes:
.LC0:
.byte 102
.byte 101
.byte 100
.byte 99
.byte 98
.byte 97
.byte 57
.byte 56
.byte 55
.byte 54
.byte 53
.byte 52
.byte 51
.byte 50
.byte 49
.byte 48
.align 4
.LC1:
.short 1
.short 2
.short 3
.short 4
.short 5
.short 6
.short 7
.short 8
.align 4
.LC2:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
.section ".text"
.align 2
.globl main
.type main, @function
--
Summary: wrong constants allocation for altivec data type on PPC
little-endian
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xhliu at mc dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24000
