[Bug c/102461] New: overflow in omp parallel for schedule (static,chunk_size)

[michelemartone at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461

            Bug ID: 102461
           Summary: overflow in omp parallel for schedule
                    (static,chunk_size)
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: michelemartone at users dot sourceforge.net
  Target Milestone: ---

Created attachment 51499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51499&action=edit
`git diff` output of gcc/omp-expand.c against revision 7ca388565af aka tag:
releases/gcc-11.2.0

Hi,

I am the author of the LIBRSB library [http://librsb.sourceforge.net/] for
Sparse BLAS (sparse linear algebra_ computations.
I've received a bug report [https://savannah.gnu.org/bugs/?60042#comment4]
where an OpenMP-parallelized loop between i=0..<near to INT_MAX> ended up
executing the loop body with i=-1.

The original loop in question had static scheduling and chunk_size=10000, and
even one thread is sufficient to cause the problem.

I reduced the problem and can reproduce it with gcc-11.2.0 (built from sources,
GIT tag releases/gcc-11.2.0) and older ones; arch x86_64.
I could not reproduce the problem with clang-11.0.1 or icc-19.0.5.281.  

// # gcc -Wall -Wextra -pedantic -fopenmp -std=c11 -O0 overflow.c               
#include <stdlib.h> // abort
#include <limits.h> // INT_MAX
#include <omp.h> // compile with -fopenmp
int main ()
{ 
  const int chunk_size = 1000; 
  const int n = INT_MAX - 100; // 2147483547
  int l = 0;
  #pragma omp parallel for schedule (static,chunk_size) num_threads (1)
  for (int i = 0; i < n; ++i)
    { 
      l = i; 
      if(i < 0)
        abort ();
    }
  if ( l != n-1 )
    abort ();
  return 0;
}

I made some experiments in gcc/omp-expand.c and came up with a fix to insert
overflow detection code when computing the lower and upper boundaries of the
current chunk, thus avoiding the loop body from being executed with i=-1.
Invoking patched gcc like:

FIX1=1 FIX2=1 FIX3=1 gcc -fopenmp -Wall -pedantic -O0 overflow_mini.c -o
overflow -fdump-tree-all

and looking at the *.ompexp file it dumps, one can get an idea of what was
going wrong with the original flow.

Unfortunately I was not able to make my patch generate correct code for -O1 or
more.

I am attaching `git diff` output of gcc/omp-expand.c against revision
7ca388565af aka tag: releases/gcc-11.2.0 -- so one may use this as a base to
fix the bug fully.

I hope this information is enough for you GCC/OpenMP folks to fix this problem!

Michele