From patchwork Wed Mar 1 09:58:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 65832 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8048B3858C83 for ; Wed, 1 Mar 2023 09:58:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8048B3858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677664738; bh=/ShuZLPFznPGYmPHabaJoR8pVVO4WXRJQrI0/BUpSlM=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=l42BVroy/OUcFDkWnz1CU9LSQhm1MKiewXAotjHcxFe0SCXKwfX2urng/GZwUkow0 PrA3WHFsz7uUvVKq4WICUrzqd40x2RK6bE+MHghH5tW5zpQHwE5SVzZ4eknTwIKdXE a/tya9Zcq0yEXa4Kzqp6d2PdRyvlA7iGRtKSXuOU= 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.129.124]) by sourceware.org (Postfix) with ESMTPS id 8E9333858D33 for ; Wed, 1 Mar 2023 09:58:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E9333858D33 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-219-stMblNxXPmyXbRTpJLI7cg-1; Wed, 01 Mar 2023 04:58:25 -0500 X-MC-Unique: stMblNxXPmyXbRTpJLI7cg-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 A029485A5B1; Wed, 1 Mar 2023 09:58:24 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 078831121315; Wed, 1 Mar 2023 09:58:23 +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 3219wGGk1626176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 1 Mar 2023 10:58:16 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3219wFSG1626175; Wed, 1 Mar 2023 10:58:15 +0100 Date: Wed, 1 Mar 2023 10:58:14 +0100 To: Qing Zhao , Richard Biener , "gcc-patches@gcc.gnu.org" Subject: [committed] ubsan: Add another testcase for [0] array in the middle of struct [PR108894] Message-ID: References: <50C5DFA0-F8A5-4E1A-8353-FBF3CABF3F4B@oracle.com> <9B0A086B-0C48-4038-AD6F-BD18DFBCAEF3@oracle.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! On Tue, Feb 28, 2023 at 10:59:03PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Tue, Feb 28, 2023 at 07:19:40PM +0000, Qing Zhao wrote: > > Understood. > > So, your patch fixed this bug, and then [0] arrays are instrumented by default with this patch. > > > > > Well, it would complain about > > > struct S { int a; int b[0]; int c; } s; > > > ... &s.b[1] ... > > > for C++, but not for C. > > > > A little confused here: [0] arrays were instrumented by default for C++ if it’s not a trailing array, but not for C? > > Given say > struct S { int a; int b[0]; int c; } s; > > int > main () > { > int *volatile p = &s.b[0]; > p = &s.b[1]; > int volatile q = s.b[0]; > } And, when I wrote such a testcase, I thought it would be worth it to have it in the testsuite too. Tested on x86_64-linux -m32/-m64, committed to trunk as obvious: 2023-03-01 Jakub Jelinek PR sanitizer/108894 * c-c++-common/ubsan/bounds-16.c: New test. Jakub --- gcc/testsuite/c-c++-common/ubsan/bounds-16.c.jj 2023-03-01 10:35:29.751959193 +0100 +++ gcc/testsuite/c-c++-common/ubsan/bounds-16.c 2023-03-01 10:38:09.087645556 +0100 @@ -0,0 +1,15 @@ +/* PR sanitizer/108894 */ +/* { dg-do run } */ +/* { dg-options "-fsanitize=bounds -fsanitize-recover=bounds" } */ +/* { dg-output "index 1 out of bounds for type 'int \\\[\[*0-9x]*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */ +/* { dg-output "\[^\n\r]*index 0 out of bounds for type 'int \\\[\[*0-9x]*\\\]'" } */ + +struct S { int a; int b[0]; int c; } s; + +int +main () +{ + int *volatile p = &s.b[0]; + p = &s.b[1]; + int volatile q = s.b[0]; +}