This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/24000] New: wrong constants allocation for altivec data type on PPC little-endian


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  ...?...@..@@...@
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  ...@..@@...@...?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]