https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461
--- Comment #5 from Michele Martone <michelemartone at users dot sourceforge.net> --- Hi Jakub. Thanks for confirming the details of the algorithm determining the boundaries. If we take Table 2.5 of the OpenMP spec: https://www.openmp.org/spec-html/5.1/openmpsu48.html#x73-73045 it says about "static": "iterations are divided into chunks of size chunk_size". So already sticking to that (so, performing that division) would avoid the problem here. To me, this nails down the issue as a bug. If you can use a non-division based arithmetic to get around it would be fine as well. Indeed, as of now some more resilience for these loops would be nice.. >From the user perspective, the idea of getting an overflow with one thread (case here) is odd: one may be tempted to think that in this special case no computation at all happens. Moreover, nowadays is pretty easy for the loop range to get near to INT_MAX, and then an overflow situation here may arise even if e.g. n = 2000000000, chunk_size = 1080000000 (so something more than n/2) and 1 thread. I hope the overflow-avoiding version makes it in soon here (just as with dynamic or guided)!
