http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52348
Bug #: 52348
Summary: [4.5/4.6] OpenMP incorrectly parallelizes loops (wrong
iteration count)
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ua_gcc_bugzi...@binary-island.eu
Created attachment 26725
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26725
testcase with unsigned and signed integers (OpenMP >= 3.0 / < 3.0)
The attached testcase shows actually two possible bugs:
(1) Using the data type's maximum value range as the number of iterations, will
result in less iterations if and only if more than 1 thread is used. Gradually
increasing the number of threads and slowly decreasing the iteration count,
will produce the right result.
(2) Using a signed range for the loop counter (starting from the negative min
to the positive max), will not work at all. No loop iteration is done. As long
as the program is linked with openmp, this does not change. Recompiling without
openmp support, produces the right result.
This behavior has been reproduced with gcc 4.5.3, 4.6.2 and current 4.6 branch
(aka the upcoming 4.6.3). Current gcc 4.7 trunk does work partially: it
produces the right results for the unsigned range but still does not work for
the signed range. The selected target (64bit / 32bit) or optimizations (Os up
to O3) make no difference at all.
The expected output would be:
INT32_MAX: 65535 / 65535
UINT32_MAX: 65535 / 65535
The OpenMP < 3.0 part (signed integer range) works correctly with the path64
compiler and both parts also work correctly with the Intel C compiler.
All tests were performed on a x86_64 (Core i7 860) Gentoo system with glibc
2.14.1(-r2) and binutils-2.22(-r1).
