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
