public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/52348] New: [4.5/4.6] OpenMP incorrectly parallelizes loops (wrong iteration count)
@ 2012-02-23  9:22 ua_gcc_bugzilla@binary-island.eu
  2012-02-23  9:53 ` [Bug libgomp/52348] [4.5/4.6/4.7] " ua_gcc_bugzilla@binary-island.eu
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: ua_gcc_bugzilla@binary-island.eu @ 2012-02-23  9:22 UTC (permalink / raw)
  To: gcc-bugs

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: unassigned@gcc.gnu.org
        ReportedBy: ua_gcc_bugzilla@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).


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-02-23 10:39 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-23  9:22 [Bug libgomp/52348] New: [4.5/4.6] OpenMP incorrectly parallelizes loops (wrong iteration count) ua_gcc_bugzilla@binary-island.eu
2012-02-23  9:53 ` [Bug libgomp/52348] [4.5/4.6/4.7] " ua_gcc_bugzilla@binary-island.eu
2012-02-23 10:08 ` [Bug libgomp/52348] " rguenth at gcc dot gnu.org
2012-02-23 10:29 ` ua_gcc_bugzilla@binary-island.eu
2012-02-23 10:39 ` [Bug libgomp/52348] [4.5/4.6/4.7] " jakub at gcc dot gnu.org
2012-02-23 10:47 ` ua_gcc_bugzilla@binary-island.eu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).