[Bug c/61050] New: OpenMP: wrong behavior of 'omp for' on corner cases

[Bug c/61050] New: OpenMP: wrong behavior of 'omp for' on corner cases

[guido at vanguardiasur dot com.ar]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61050

            Bug ID: 61050
           Summary: OpenMP: wrong behavior of 'omp for' on corner cases
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: guido at vanguardiasur dot com.ar

Created attachment 32728
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32728&action=edit
example input

Note: by infinite loop, we mean something of the form 'for (i=0; i>=0; i++)',
not considering overflow.

#pragma omp for changes the behavior of empty/infinite loops. Some empty loops
are entered once per thread, and some infinite loops are either not entered at
all or entered once. An example is attached and more are found in [1].

In the attached example, this loop:

    char i;
    #pragma omp for
    for (i=100; i<90; i--)
        printf("Hello %i %i\n", i, omp_get_thread_num());

is entered exactly once, with i = 100, when it should never be entered. There
are no parallel directives.

We believe this is caused by a miscalculation of the number of iterations, or a
wrong empty loop check (or both).
The calculated number of iterations (extracted from the assembly) for the
previous example is 12, when it should probably be zero. Also, some loops give
a negative loop count but are still entered (once).

This happens on gcc 4.9.0, 4.8.2 and some older versions too. We've reproduced
it easily. We checked the OpenMP specification and it does not mention an
exception in these cases. Also note, this behavior does not seem to occur in
fortran.

gcc -v -save-temps output at http://sprunge.us/TfaC.

[1]
    http://sprunge.us/TbWj
    http://sprunge.us/NCeA
    http://sprunge.us/PAZD
    http://sprunge.us/faTD
    http://sprunge.us/CIMN

[Bug c/61050] OpenMP: wrong behavior of 'omp for' on corner cases

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61050

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is undefined behavior.
See OpenMP 4.0, 2.6, lines 18-26 on page 52:

"The following restrictions also apply:

- If test-expr is of the form var relational-op b and relational-op is < or <=
then incr-expr must cause var to increase on each iteration of the loop. If
test-expr is of the form var relational-op b and relational-op is > or >= then
incr-expr must cause var to decrease on each iteration of the loop.

- If test-expr is of the form b relational-op var and relational-op is < or <=
then incr-expr must cause var to decrease on each iteration of the loop. If
test-expr is of the form b relational-op var and relational-op is > or >= then
incr-expr must cause var to increase on each iteration of the loop."

Other versions of the standard have similar wording.
Not every valid C/C++ for loop is valid OpenMP #pragma omp
{for,simd,distribute} loop.

[Bug c/61050] OpenMP: wrong behavior of 'omp for' on corner cases

[guido at vanguardiasur dot com.ar]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61050

--- Comment #2 from Guido Martínez <guido at vanguardiasur dot com.ar> ---
(In reply to Jakub Jelinek from comment #1)
> This is undefined behavior.
> See OpenMP 4.0, 2.6, lines 18-26 on page 52:
> 
> "The following restrictions also apply:
> 
> - If test-expr is of the form var relational-op b and relational-op is < or
> <= then incr-expr must cause var to increase on each iteration of the loop.
> If test-expr is of the form var relational-op b and relational-op is > or >=
> then incr-expr must cause var to decrease on each iteration of the loop.
> 
> - If test-expr is of the form b relational-op var and relational-op is < or
> <= then incr-expr must cause var to decrease on each iteration of the loop.
> If test-expr is of the form b relational-op var and relational-op is > or >=
> then incr-expr must cause var to increase on each iteration of the loop."
I see. I apologize for reporting this, then.
>From gcc-bugs-return-450528-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun May 04 22:57:08 2014
Return-Path: <gcc-bugs-return-450528-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5789 invoked by alias); 4 May 2014 22:57:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5717 invoked by uid 48); 4 May 2014 22:57:01 -0000
From: "marcel at telka dot sk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/42145] Incorrect "may be used uninitialized warning" for a very specific test case
Date: Sun, 04 May 2014 22:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marcel at telka dot sk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-42145-4-XqpIbuIS34@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-42145-4@http.gcc.gnu.org/bugzilla/>
References: <bug-42145-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00220.txt.bz2
Content-length: 1249

http://gcc.gnu.org/bugzilla/show_bug.cgi?idB145

--- Comment #11 from Marcel Telka <marcel at telka dot sk> ---
It is reproducible even with -O1:

int f(void);

int
main(void)
{
        int a, b;

        a = f();
        if (a)
                b = f();

        if (a && b)
                return 1;

        return 0;
}


$ gcc -O1 -Wuninitialized -c a.c
a.c: In function 'main':
a.c:12:15: warning: 'b' may be used uninitialized in this function
[-Wmaybe-uninitialized]
         if (a && b)
               ^
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/lto-wrapper
Target: sparc-sun-solaris2.11
Configured with:
/ws/builds2/jenkins/src/du/dilos-userland-review/components/gcc48/gcc-4.8.2/configure
--prefix=/usr/gcc/4.8 --mandir=/usr/gcc/4.8/share/man --bindir=/usr/gcc/4.8/bin
--libdir=/usr/gcc/4.8/lib --sbindir=/usr/gcc/4.8/sbin --infodir=/usr/share/info
--without-gnu-as --with-as=/usr/bin/as --build=sparc-sun-solaris2.11
--infodir=/usr/gcc/4.8/share/info --libexecdir=/usr/gcc/4.8/lib
--enable-languages=c,c++,fortran,objc --enable-shared
--enable-targets=sparcv9-sun-solaris2.11 --without-gnu-ld --with-ld=/usr/bin/ld
Thread model: posix
gcc version 4.8.2 (GCC)
$