Intel C++ Compiler bug triggered by ROOT

Hi,

The following is not strictly speaking a bug of ROOT:

I am not sure how many people actually are compiling ROOT with an up-to-date Intel C++ Compiler. It seems that with the default (-O == -O2 in the Makefile.linuxicc) there are serious issue with writing ROOT files. You might want to use either -O1 or disable the inline assembly byte-swapping in ROOT.

The reason for this is ROOT uses inline assembly for byte swapping on IA-32, and in the current Intel C++ Compiler (9.1.043), parameter passing into inline assembly are sometimes are not initialized properly. The result is corrupted ROOT files being written with (repeated) random entries instead of the actual data.

This behavior can be demonstrated/reproduced with the simple test case:

#include <cstdio>

#define R__bswap_32(x) \
({ register unsigned int __v; \
__asm__ __volatile__ ("bswap %0" \
                : "=r" (__v) \
                : "0" ((unsigned int)(x))); \
__v; })

int main(void)
{
const float x = 1;

for(int i = 0; i < 8; i++)
     fprintf(stderr, "0x%08x\n", R__bswap_32(*((unsigned int *)&x)));

return 0;
}

The code will 8 same random uninitialized values with Intel C++ Compiler 9.1.043, instead of printing 8 lines of “0x0000803f” (the byte swapped IEEE single precision 1.0F), as it gives with -O1 or below, or with GCC.

If you check the assembly code generate with -O2, (%esp) is loaded for byte swapping, but above that, nowhere were any initialization of (%esp):

..B1.7:                         # Preds ..B1.1
        addl      $4, %esp                                      #11.1
        movl      $-8, %eax                                     #14.9
        movl      %eax, %ebx                                    #14.9
                                # LOE ebx esi edi
..B1.2:                         # Preds ..B1.7 ..B1.3
        lea       (%esp), %edx                                  #15.34
        movl      (%edx), %ecx                                  #15.0
# Begin ASM
        bswap %ecx
# End ASM                                                       #15.0

whereas in -O1, this was accomplished by:

        fld1                                                    #12.13
        addl      $4, %esp                                      #11.1
        fstps     (%esp)                                        #12.13

or in GCC with -O3 (note the initialization of %esi and then %eax):

        movl    $1065353216, %esi
        movl    $7, %ebx
        .p2align 2,,3
.L5:
        movl    %esi, %eax
#APP
        bswap %eax
#NO_APP

I submitted this issue to Intel, and wonder what they say.

Best,

Yue Shi Lai

Thanks for having reported this to Intel (can you mail me the premier probem report number). I’ve good experience with the speed with which they fix things, but this is indeed a big bug.

I’ve verified that the latest icc (9.1.030) on Mac OS X has the same problem even upto -O0:

(macrdm) [136] icc -O3 -o bswap bswap.cxx 
(macrdm) [137] ./bswap 
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
(macrdm) [138] icc -O2 -o bswap bswap.cxx 
(macrdm) [139] ./bswap 
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
(macrdm) [140] icc -O1 -o bswap bswap.cxx 
(macrdm) [141] ./bswap 
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
(macrdm) [142] icc -O0 -o bswap bswap.cxx 
(macrdm) [143] ./bswap 
0x0000803f
0x0000803f
0x0000803f
0x0000803f
0x0000803f
0x0000803f
0x0000803f
0x0000803f

Cheers, Fons.

Intel released the Intel C++ Compiler Version 9.1.046 (Build 20070109Z), which appears to have fixed the problem.