Take the testcase for 39495, and add the "schedule(dynamic)" clause to the for
loop:
#include <stdlib.h>
#include <omp.h>
void foo(unsigned ub, unsigned *array)
{
unsigned i;
// test passes for N >= 1
#define N 0
#pragma omp for schedule(dynamic)
for (i = ub; i > N; i -=2) {
array[i] = i;
}
}
and compile with gcc -fopenmp -S. Look at the way the parameters are set up
for the GOMP_loop_dynamic_start call:
movl $1, %ecx
movl $4294967294, %edx
movl $0, %esi
movq %rax, %rdi
call GOMP_loop_dynamic_start
This looks like ia32 codegen to me - 1 is moved into %ecx, not %rcx, and 0 is
moved into %esi, not %rsi. The harware zero extends the %e?x registers out to
64 bits (not sure if you can rely on that or if the extended bit values are
undefined), so that doesn't cause a failure. What causes the full testcase to
crash is that moving 4294967294 into %edx causes %rdx = 0x00000000fffffffe, not
0xfffffffffffffffe = -2, the stride. Whatever - it's obvious an ia32 code
fragment was selected instead of the intel64 version.
--
Summary: Bad Intel64 codegen for modified 39495 testcase
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brian dot e dot bliss at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40967
