From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F27563858C60; Mon, 24 Jan 2022 10:28:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F27563858C60 From: "michelemartone at users dot sourceforge.net" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/102461] overflow in omp parallel for schedule (static,chunk_size) Date: Mon, 24 Jan 2022 10:28:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: michelemartone at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 10:28:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102461 --- Comment #5 from Michele Martone --- Hi Jakub. Thanks for confirming the details of the algorithm determining the boundari= es. 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 fi= ne 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 =3D 2000000000, chunk_size =3D 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)!=