From patchwork Tue Sep 12 07:02:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 75701 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 A195C385828D for ; Tue, 12 Sep 2023 07:03:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A195C385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694502210; bh=8lotJGt/D6O4vFT5+SYgCLHaGKEqHgE5psQbSi92NIY=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=u/fnS/Cgex1pmPN86oBbtruhANJqYt6wta5aj439b9B/iha+bMgjTtza+i8weeckk nvUjKoxlxljSDIYr8qHN1lES09NZg/0in73+ridYH36duaw7TKHaJzIIrNEIjFaQrU 5EumorNCnnU+LHvGSmIINLqEUArUHlYDZ9NiAYqc= 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 35C803858C30 for ; Tue, 12 Sep 2023 07:03:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 35C803858C30 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-364-yY5fgeQ5OTKTOiQAqisZSQ-1; Tue, 12 Sep 2023 03:02:58 -0400 X-MC-Unique: yY5fgeQ5OTKTOiQAqisZSQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0B14101FAA1; Tue, 12 Sep 2023 07:02:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.209]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 647862026D68; Tue, 12 Sep 2023 07:02:57 +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 38C72tZS3696663 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 12 Sep 2023 09:02:55 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 38C72tVr3696662; Tue, 12 Sep 2023 09:02:55 +0200 Date: Tue, 12 Sep 2023 09:02:55 +0200 To: Benjamin Priour , David Malcolm Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] Message-ID: References: <202309092344.389NiSeQ3407880@shliclel4214.sh.intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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_H3, RCVD_IN_MSPIKE_WL, 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.30 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" On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote: > > Thanks for the report, > > > > After investigation it seems the location of the new dejagnu directive for > > C++ differs depending on the configuration. > > The expected warning is still emitted, but its location differ slightly. > > I expect it to be not an issue per se of the analyzer, but a divergence in > > the FE between the two configurations. > > I think the divergence is whether called_by_test_5b returns the struct > in registers or in memory. If in memory (like in the x86_64 -m32 case), we have > [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b (); [return slot optimization] > [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v} {CLOBBER(eol)}; > [compound-assignment-1.c:72:1] return; > in the IL, while if in registers (like x86_64 -m64 case), just > [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b (); > [compound-assignment-1.c:72:1] return; > > If you just want to avoid the differences, putting } on the same line as the > call might be a usable workaround for that. Here is the workaround in patch form. Tested on x86_64-linux -m32/-m64, ok for trunk? 2023-09-12 Jakub Jelinek PR testsuite/111377 * c-c++-common/analyzer/compound-assignment-1.c (test_5b): Move closing } to the same line as the call to work-around differences in diagnostics line. Jakub --- gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c.jj 2023-09-11 11:05:47.523727789 +0200 +++ gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c 2023-09-12 08:58:52.854231161 +0200 @@ -68,5 +68,8 @@ called_by_test_5b (void) void test_5b (void) { - called_by_test_5b (); -} /* { dg-warning "leak of '.ptr_wrapper::ptr'" "" { target c++ } } */ + called_by_test_5b (); } +/* { dg-warning "leak of '.ptr_wrapper::ptr'" "" { target c++ } .-1 } */ +/* The closing } above is intentionally on the same line as the call, because + otherwise the exact line of the diagnostics depends on whether the + called_by_test_5b () call satisfies aggregate_value_p or not. */