Bug 225165 – gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled with it can yield wrong results or even segfault)

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Alessandro Salvatori 2008-06-07 00:54:26 UTC]

gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled with it can yield wrong results or even segfault)

In the example source code below, the second array is incorrectly interpreted by the code generated by gcc 3.4.6 as if it were at a different location than it actually is. Instead, gcc 2.95.3 and 4.1.2 show the right behavior.

I've checked this both on x86 and ppc, and it happens on both platforms.

The difference in the x86 assembly seems to be the following, and in fact pushing and popping with printf()s scattered all over the accesses to the vector elements seems a viable yet horrible workaround:

| bash-3.00$ diff -U10 buglet.s-{mv3.4.3,2.95.3}
| --- buglet.s-3.4.3    2008-05-28 16:03:47.000000000 -0700
| +++ buglet.s-2.95.3     2008-05-28 16:01:53.000000000 -0700
| @@ -111,5 +111,5 @@
|         leal    -8(%ebp), %esp
|         popl    %esi
|         popl    %edi
| -       popl    %ebp
| +       leave
|         ret
|         .size   main, .-main
|         .section        .note.GNU-stack,"",@progbits



Reproducible: Always

Steps to Reproduce:
Try and build the following code:

int main(){
     struct input_{
         unsigned int num;
         unsigned int key_siz;
         unsigned int val_siz;
         unsigned char key [ 5 ] [ 3 ];
         unsigned char val [ 5 ] [ 6 ];
     } __attribute__((packed)) input = {
         5,
         3,
         6,
         {
             'a', 'b', 'c',
             'd', 'e', 'f',
             'g', 'h', 'i',
             'j', 'k', 'l',
             'm', 'n', 'o',
         },
         {
             'A', 'B', 'C', 'D', 'E', 'F',
             'G', 'H', 'I', 'J', 'K', 'L',
             'M', 'N', 'O', 'P', 'Q', 'R',
             'S', 'T', 'U', 'V', 'W', 'X',
             'Y', 'Z', '0', '1', '2', '3',
         },
     };
 
     unsigned int num = input.num;
     unsigned int key_siz = input.key_siz;
     unsigned int val_siz = input.val_siz;
 
     struct payload_ {
         unsigned int num;
         unsigned int key_siz;
         unsigned int val_siz;
         unsigned char key [ num ] [ key_siz ];
         unsigned char val [ num ] [ val_siz ];
     } __attribute__((packed)) * data = (struct payload_ *)&input;
 
     while(num--){
         printf("%3.3s -> %6.6s\n", data->key[num], data->val[num]);
     }
 
     return 0;
 }


Actual Results:  

The binary produced by gcc 3.4.6 shows wrong results:

$ ./buglet-gcc-3.4.6
mno -> VWXYZ0
jkl -> MNOPQR
ghi -> DEFGHI
def -> jklmno
abc -> abcdef


Expected Results:  
The binary produced by gcc 2.95.3 or 4.1.2 shows the correct results:

$ ./buglet-gcc-4.1.2 [or ./buglet-gcc-2.95.3]
mno -> YZ0123
jkl -> STUVWX
ghi -> MNOPQR
def -> GHIJKL
abc -> ABCDEF


In my actual code, perhaps because of the much larger indexes, I get segmentation faults in unpredictable places... These don't happen with good compilers, of course.

[Comment 1 Carsten Lohrke (RETIRED) 2008-06-07 09:57:53 UTC]

Low chance to get this fixed, unless you provide a patch. The toolchain team does support gcc 4 and up only. Forwarding you nevertheless...

[Comment 2 Mark Loeser (RETIRED) 2008-07-05 14:52:11 UTC]

Use a newer version of gcc.  We keep around a single version of older gcc's as a convenience to our users that have specific needs.