Message ID | ZBQhTHb0CzN5mx/N@tucnak |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp210574wrt; Fri, 17 Mar 2023 01:14:56 -0700 (PDT) X-Google-Smtp-Source: AK7set+4aZtX5POn3shAQZIn4aQbPHBg5tLWVO8lVM0CotRPhh46j4B2LcM/+hjgS0NV5ZmnIYI5 X-Received: by 2002:aa7:c84c:0:b0:4fb:9fd4:6ac5 with SMTP id g12-20020aa7c84c000000b004fb9fd46ac5mr2163436edt.14.1679040896730; Fri, 17 Mar 2023 01:14:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679040896; cv=none; d=google.com; s=arc-20160816; b=LWelAyk5FvK4DRi3V3snnuO8Pwi2h4ZI8IkyuLjQtYXWXh7MHSmiosf0DKtV1HmwgK cXIq8LEPKe2KdFQfKpGW3jQmD2diyNT7Ei3ilBn1y0ACKWE2OelEBmtCnm0ejEH9jm14 ae0Iw0XOw45tWgiodeEyKFrmBZ5kp1unC+4Nt5peo1rfMj5sF4ZMlzKn41uO7kbrTLKw pED0s43NpoKlVmSefIrxvleSogmwV6iSIW5BWgLqtS/WCzoEMrVjl8IDSZQJqIcAxdw6 LAU1nfeZ7zLStuo4ZGV0GGIp5MijukLR1B770J3XOfQXAL6gIaSfbKaGsDjxLmq8RU6H lgTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:message-id:subject:cc:to:date :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=YU5Z62lsSj/CAK1ANW65Y+Ej8uEOtU5dLuokw2x4wGU=; b=gcvj9ip5uTxcRNV8bgt0/reYpYA0FrKe5PtGCX0mufQ1NyQmMb8ED6TIIV3TEg9wgz PPnHm+TWh0a052nhLuHAub88HVaCKvWFckJdzzM1+MMEaFDbvpK/MfBSTaKXh2IO4k6B MB46oxjQrER0ikgPJO0r30cFJHzwyyQ7SBf7ACSe99Q42kbGn4Fqp1lzr77xXOYGQHRl dC5wELPr6HS7CYSEXUKHyoqF1Z/zNd4oQW+/PZozom5TkLIcD4sLzJ2Gn572eSk5LfJh Ub51iTbPy59ZRYyJp6HF4eLLRWqCMafaXrXRyS58J6geltPyHlwOGy3rPKyt1for8n+L iQZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=mR1yc5Ph; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id l3-20020aa7d943000000b004acda4c9666si1977259eds.225.2023.03.17.01.14.56 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 01:14:56 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=mR1yc5Ph; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8590138555A0 for <ouuuleilei@gmail.com>; Fri, 17 Mar 2023 08:14:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8590138555A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679040895; bh=YU5Z62lsSj/CAK1ANW65Y+Ej8uEOtU5dLuokw2x4wGU=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=mR1yc5PhY6RQLPiDPiP8uMoGRFjd/9P1eaRE/wV/XrkJVSmN2EvT4HbGqtnJLRJ3p sHl1smU6jnK8lXJQ9XI0juab0jq4UQY8Yk6BiOpRg9/Is2esB9TCVehRy07PO+HliJ 0iXmoosqz61nCST9LEkWdK6liSoQVQQWzbcvaIMI= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id DB4273858423 for <gcc-patches@gcc.gnu.org>; Fri, 17 Mar 2023 08:14:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB4273858423 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-26-_XIIGopfPo61wKvCitwW0Q-1; Fri, 17 Mar 2023 04:14:09 -0400 X-MC-Unique: _XIIGopfPo61wKvCitwW0Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 46EF7811E7D; Fri, 17 Mar 2023 08:14:09 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D6D0B1121315; Fri, 17 Mar 2023 08:14:08 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 32H8E6LS901946 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 17 Mar 2023 09:14:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32H8E5ob901945; Fri, 17 Mar 2023 09:14:05 +0100 Date: Fri, 17 Mar 2023 09:14:04 +0100 To: "Joseph S. Myers" <joseph@codesourcery.com>, Marek Polacek <polacek@redhat.com>, Richard Biener <rguenther@suse.de> Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] c, ubsan: Instrument even shortened divisions [PR109151] Message-ID: <ZBQhTHb0CzN5mx/N@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760601987597601939?= X-GMAIL-MSGID: =?utf-8?q?1760601987597601939?= |
Series |
c, ubsan: Instrument even shortened divisions [PR109151]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Jakub Jelinek
March 17, 2023, 8:14 a.m. UTC
Hi! On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk, or shall I omit the second hunk? 2023-03-17 Jakub Jelinek <jakub@redhat.com> PR c/109151 * c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test. Jakub
Comments
On Fri, 17 Mar 2023, Jakub Jelinek wrote: > Hi! > > On the following testcase, the C FE decides to shorten the division because > it has a guarantee that INT_MIN / -1 division won't be encountered, the > first operand is widened from narrower unsigned and/or the second operand is > a constant other than all ones (in this case both are true). > The problem is that the narrower type in this case is _Bool and > ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE > or REAL_TYPE. Strangely this doesn't happen in C++ FE. > Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, > so I think we should be fine even with -fstrict-enums in C++ in case it > shortened to ENUMERAL_TYPEs. > > The following patch just instruments those on the ubsan_instrument_division > side. Perhaps only the first hunk and testcase might be needed because > we shouldn't shorten if the other case could be triggered. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk, > or shall I omit the second hunk? LGTM as-is Richard. > 2023-03-17 Jakub Jelinek <jakub@redhat.com> > > PR c/109151 > * c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral > types rather than just INTEGER_TYPE. > > * c-c++-common/ubsan/div-by-zero-8.c: New test. > > --- gcc/c-family/c-ubsan.cc.jj 2023-02-28 11:38:28.965868044 +0100 > +++ gcc/c-family/c-ubsan.cc 2023-03-16 09:49:51.651126302 +0100 > @@ -53,7 +53,7 @@ ubsan_instrument_division (location_t lo > op0 = unshare_expr (op0); > op1 = unshare_expr (op1); > > - if (TREE_CODE (type) == INTEGER_TYPE > + if (INTEGRAL_TYPE_P (type) > && sanitize_flags_p (SANITIZE_DIVIDE)) > t = fold_build2 (EQ_EXPR, boolean_type_node, > op1, build_int_cst (type, 0)); > @@ -68,7 +68,7 @@ ubsan_instrument_division (location_t lo > t = NULL_TREE; > > /* We check INT_MIN / -1 only for signed types. */ > - if (TREE_CODE (type) == INTEGER_TYPE > + if (INTEGRAL_TYPE_P (type) > && sanitize_flags_p (SANITIZE_SI_OVERFLOW) > && !TYPE_UNSIGNED (type)) > { > --- gcc/testsuite/c-c++-common/ubsan/div-by-zero-8.c.jj 2023-03-16 10:01:31.626824994 +0100 > +++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-8.c 2023-03-16 10:03:05.510443440 +0100 > @@ -0,0 +1,14 @@ > +/* PR c/109151 */ > +/* { dg-do run } */ > +/* { dg-options "-fsanitize=integer-divide-by-zero -Wno-div-by-zero -fno-sanitize-recover=integer-divide-by-zero" } */ > +/* { dg-shouldfail "ubsan" } */ > + > +int d; > + > +int > +main () > +{ > + d = ((short) (d == 1 | d > 9)) / 0; > +} > + > +/* { dg-output "division by zero" } */ > > Jakub > >
On Fri, Mar 17, 2023 at 09:14:04AM +0100, Jakub Jelinek wrote: > Hi! > > On the following testcase, the C FE decides to shorten the division because > it has a guarantee that INT_MIN / -1 division won't be encountered, the > first operand is widened from narrower unsigned and/or the second operand is > a constant other than all ones (in this case both are true). > The problem is that the narrower type in this case is _Bool and > ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE > or REAL_TYPE. Strangely this doesn't happen in C++ FE. I was curious. The difference is because C++ passes this (gdb) pge op0 (int) (short int) (VIEW_CONVERT_EXPR<int>(d) == 1 | VIEW_CONVERT_EXPR<int>(d) > 9) to shorten_binary_op while C passes: (gdb) pge op0 (int) (<<< Unknown tree: c_maybe_const_expr d >>> == 1 || <<< Unknown tree: c_maybe_const_expr d >>> > 9) so when we remove the '(int)' cast, we have different types underneath, either short or bool. In C, the BIT_IOR_EXPR -> TRUTH_OR_EXPR change is because we call c_convert -> convert_to_integer -> do_narrow. In C++, we never called do_narrow so shorten_binary_op gets the original tree. Anyway, thanks for the patch. Marek
--- gcc/c-family/c-ubsan.cc.jj 2023-02-28 11:38:28.965868044 +0100 +++ gcc/c-family/c-ubsan.cc 2023-03-16 09:49:51.651126302 +0100 @@ -53,7 +53,7 @@ ubsan_instrument_division (location_t lo op0 = unshare_expr (op0); op1 = unshare_expr (op1); - if (TREE_CODE (type) == INTEGER_TYPE + if (INTEGRAL_TYPE_P (type) && sanitize_flags_p (SANITIZE_DIVIDE)) t = fold_build2 (EQ_EXPR, boolean_type_node, op1, build_int_cst (type, 0)); @@ -68,7 +68,7 @@ ubsan_instrument_division (location_t lo t = NULL_TREE; /* We check INT_MIN / -1 only for signed types. */ - if (TREE_CODE (type) == INTEGER_TYPE + if (INTEGRAL_TYPE_P (type) && sanitize_flags_p (SANITIZE_SI_OVERFLOW) && !TYPE_UNSIGNED (type)) { --- gcc/testsuite/c-c++-common/ubsan/div-by-zero-8.c.jj 2023-03-16 10:01:31.626824994 +0100 +++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-8.c 2023-03-16 10:03:05.510443440 +0100 @@ -0,0 +1,14 @@ +/* PR c/109151 */ +/* { dg-do run } */ +/* { dg-options "-fsanitize=integer-divide-by-zero -Wno-div-by-zero -fno-sanitize-recover=integer-divide-by-zero" } */ +/* { dg-shouldfail "ubsan" } */ + +int d; + +int +main () +{ + d = ((short) (d == 1 | d > 9)) / 0; +} + +/* { dg-output "division by zero" } */