From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E2CA73858D37; Thu, 3 Feb 2022 07:32:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2CA73858D37 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases Date: Thu, 03 Feb 2022 07:32:22 +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: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org 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: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Thu, 03 Feb 2022 07:32:23 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104356 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Hmm, but doesn't ada enable -fdelete-dead-exceptions? That is, I'm not sure we make division by zero well-defined with -fnon-call-exceptions - the transform assumes the exception cannot happen (because undefinedness) and removes the exceptional path. So do we, with -fnon-call-exceptions, make division by zero throw an except= ion instead of invoking undefined behavior? (that is, on the non-exceptional path we can still assume the divisor is not zero after the division) Our docs say @item -fnon-call-exceptions @opindex fnon-call-exceptions Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does not exist everywhere. Moreover, it only allows @emph{trapping} instructions to throw exceptions, i.e.@: memory references or floating-point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as @code{SIGALRM}. This enables @option{-fexceptions}. which doesn't mention integer division by zero or arbitrary instructions of the ISA that may raise an exception under some circumstances (IIRC some x86 ones raise exceptions on overflow for example). Like the C standard would allow the CPU to raise an exception on out-of-bound shifts (since those invoke undefined behavior) - if the CPU would, would -fnon-call-exceptions imply it's now implementation defined (throw an exception?)? Of course integer division might be special enough to single out as IIRC all CPUs trap on that (I'm sure somebody knows one that does not...).=