From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AB6023861813; Thu, 15 Feb 2024 01:22:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB6023861813 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707960149; bh=JX0vkHcQCFW6VDPDmP7rj+yhT4lMj6uyQB5XUvYdYb4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cozCoi23835gL410+ddjtN1Qi118f18V7rAFrQv5Y3bb8pUuv0GeDWqVy9nvbreC2 19t1G+03jlsrNB9yhNFuEbfgUb3jUTgqiFfuvvONDfDUSK2SEsji3x0Q1S4cOC7hWL Nj6cMFBUn9qNs7Mm3r0psJi/+GqU4iSyHrn8WO/Q= From: "i at maskray dot me" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow Date: Thu, 15 Feb 2024 01:22:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: i at maskray dot me X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102317 Fangrui Song changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i at maskray dot me --- Comment #13 from Fangrui Song --- I see a Clang patch that proposes -fsanitize=3Dsigned-integer-wrap, which a= ppears to be the same as signed-integer-overflow, but performs the check in the -fwrapv mode. I feel that it's better to make -fsanitize=3Dsigned-integer-overflow work w= ith -fwrapv https://github.com/llvm/llvm-project/pull/80089#issuecomment-1945202620 --- Copying here for folks prefer not to read github This is a UI discussion about how command line options should behave. Some folks prefer simpler rules while some prefer smart rules (guessing user intention). A [-fwrapv](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fw= rapv) user may either: * rely on the wraparound behavior * or prevent certain optimizations that would raise security concerns Our -fsanitize=3Dsigned-integer-overflow design have been assuming that -fw= rapv users don't need the check. This PR suggests that an important user does want overflow checks and our g= uess has failed. It seems very confusing to have two options doing the same thing. https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html is clear that n= ot all checks are undefined behavior in the standards. > Issues caught by this sanitizer are not undefined behavior, but are often= unintentional. Sure -fwrapv makes wraparound defined, but it doesn't prevent us from making -fsanitize=3Dsigned-integer-overflow useful. "-fwrapv =3D> no signed-integer-overflow" is not a solid argument. I think we can try making -fsanitize=3Dsigned-integer-overflow effective ev= en when -fwrapv if specified. -fsanitize=3Dsigned-integer-overflow is rare in the wild, probably rarer wh= en combined with -fwrapv. There is a precedent that -fsanitize=3Dundefined enables different checks f= or different targets. We could make -fsanitize=3Dundefined not imply -fsanitize=3Dsigned-integer-= overflow when -fwrapv is specified, if we do want to guess the user intention. Personally I'd prefer moving away from such behaviors and be more orthogona= l.=