gcc 4.7.0 for k1om codegen bug

[Hans_Vandierendonck]

Not sure where to report this for it to be heard, but I encountered a code generation bug (register assignment) when using gcc 4.7.0.

The errant C++ code:

// This code exposes a bug on gcc 4.7.0 for k1om / Xeon Phi
// where one of the int arguments is lost due to mapping
// multiple values (the argument and a temporary 1 for kmov)
// on the register eax
struct sdi {
    double m0;
    int m1;
};

extern double efunc( char * p0, char * p1, int a1, sdi a2 );

double func( char * p0, char * p1, sdi a0, int a1, sdi a2 ) {
    *((sdi *)p1) = a0;
    return efunc( p0, p1, a1, a2 );
}

# /opt/mpss/3.2.1/sysroots/x86_64-mpsssdk-linux/usr/libexec/k1om-mpss-linux/gcc/k1om-mpss-linux/4.7.0/gcc -O0 -S sdi.cc -o sdi.S

results in:

    .file    "sdi.cc"
    .text
    .globl    _Z4funcPcS_3sdiiS0_
    .type    _Z4funcPcS_3sdiiS0_, @function
_Z4funcPcS_3sdiiS0_:
.LFB0:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    subq    $64, %rsp
    movq    %rdi, -8(%rbp)
    movq    %rsi, -16(%rbp)
    movl    $1, %eax                                      # all is well here: %eax unused
    kmov    %eax, %k2
    vpackstorelpd    %zmm0, -64(%rbp){%k2}
    movq    -64(%rbp), %rsi
    movl    %edx, %eax                                 # now using %eax
    movl    %ecx, -36(%rbp)
    movl    $1, %eax                                      # Ooops!
    kmov    %eax, %k2
    vpackstorelpd    %zmm1, -64(%rbp){%k2}
    movq    -64(%rbp), %rcx
    movl    %r8d, %edx
    movq    %rsi, -32(%rbp)
    movl    %eax, -24(%rbp)
    movq    %rcx, -56(%rbp)
    movl    %edx, -48(%rbp)
    movq    -16(%rbp), %rax
    movq    -32(%rbp), %rdx
    movq    %rdx, (%rax)
    movq    -24(%rbp), %rdx
    movq    %rdx, 8(%rax)
    movq    -56(%rbp), %rax
    movl    -48(%rbp), %ecx
    movl    -36(%rbp), %edx
    movq    -16(%rbp), %rsi
    movq    -8(%rbp), %rdi
    movq    %rax, -64(%rbp)
    vbroadcastsd    -64(%rbp), %zmm0
    call    _Z5efuncPcS_i3sdi
    movl    $1, %eax
    kmov    %eax, %k2
    vpackstorelpd    %zmm0, -64(%rbp){%k2}
    movq    -64(%rbp), %rax
    movq    %rax, -64(%rbp)
    vbroadcastsd    -64(%rbp), %zmm0
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size    _Z4funcPcS_3sdiiS0_, .-_Z4funcPcS_3sdiiS0_
    .ident    "GCC: (GNU) 4.7.0 20110509 (experimental)"
    .section    .note.GNU-stack,"",@progbits

Note that the error occurs only with optimisation level -O0, not with higher levels.

I posted this also on the gcc bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63231 but people there are not interested.

Kind regards,

Hans.

[Kevin_D_Intel]

Hans, I reported this issue to the MPSS team through our Intel Premier system on your behalf. The Premier issue tracking id is: #6000066525. I will relay any communications that I receive to you via this forum post.

(Updated 10/31/2014: The internal tracking id: HSD# 5161863)

(Resolution Update on 04/08/2015): This defect is fixed the MPSS 3.5 release

[Hans_Vandierendonck]

Hi, Kevin,

Has any progress been made on resolving this bug?

Thanks,

Hans.

[Kevin_D_Intel]

Hi Hans,

There is no resolution yet. I did receive notice earlier in the week this was being investigated by the developers but there were no specifics provided. I'll keep you posted once I hear more.

[Kevin_D_Intel]

Hi Hans - I received an update that there appears to be a fix in-hand for this issue and that it is being planned for inclusion in a future release. I will let you know about the availability once I have more definitive information on that.

[Kevin_D_Intel]

Hi Hans - I was informed the fix is targeted for an MPSS release tentatively scheduled for late Q1 2015.

[Hans_Vandierendonck]

Good news.

Thanks.

[Kevin_D_Intel]

Hi Hans - The MPSS 3.5 released containing the fix for this gcc 4.7.0 issue is now available. You can refer to the Intel® Manycore Platform Software Stack (MPSS) page for some details and links to the MPSS 3.5 downloads.

Thank you for your patience in waiting for this fix.