From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DDmKDzu0sl8FZgAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 12:17:47 -0500 Received: by simark.ca (Postfix, from userid 112) id 320A81F08B; Mon, 16 Nov 2020 12:17:47 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A92AD1E552 for ; Mon, 16 Nov 2020 12:17:44 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F19053958C2A; Mon, 16 Nov 2020 17:17:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F19053958C2A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605547064; bh=Lgg3S9M/NZQrOzcftrbnLcFFy+qM7iRI5e0uIJEj2X8=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=CqGQleyavFfFUVRMQI0/e57gg2+wUzHQelVa0xEfkGSMDdWP7zYo6AH6BEdZMagp1 iyAK2f/RLPT//uDRLi+fKOE1ONRZ/0gOAmkrRK/OcnuZJpYeuRBhxzTxRq3kvE2tqC whql6q21Wvkz5cCKCZdciWThQAyFhvQmvGh0mJR0= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id B7D33384640E for ; Mon, 16 Nov 2020 17:17:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7D33384640E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-381-9-APum-nO-CWuDU1-kRB6g-1; Mon, 16 Nov 2020 12:17:38 -0500 X-MC-Unique: 9-APum-nO-CWuDU1-kRB6g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C6B1E803624 for ; Mon, 16 Nov 2020 17:17:37 +0000 (UTC) Received: from blade.nx (ovpn-114-156.ams2.redhat.com [10.36.114.156]) by smtp.corp.redhat.com (Postfix) with ESMTP id 699545C1CF for ; Mon, 16 Nov 2020 17:17:37 +0000 (UTC) Received: from blade.com (localhost [127.0.0.1]) by blade.nx (Postfix) with ESMTP id 8634D816CD2E for ; Mon, 16 Nov 2020 17:17:36 +0000 (GMT) To: gdb-patches@sourceware.org Subject: [PATCH] KFAIL variable-length array tests which fail with Clang Date: Mon, 16 Nov 2020 17:17:35 +0000 Message-Id: <1605547055-25778-1-git-send-email-gbenson@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Gary Benson via Gdb-patches Reply-To: Gary Benson Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi all, Clang describes the upper bounds of variable length arrays using a DW_AT_count attribute which references the DIE of a synthetic variable whose value is specified using a DW_AT_location. In some cases GDB correctly handles these, but in other cases GDB adds an extra dereference causing the test to fail. This commit marks these failing tests as caused by PR gdb/26905 when the test executable was built using Clang. Checked on Fedora 32 x86_64, with GCC and Clang. Ok to commit? Thanks, Gary --- gdb/testsuite/ChangeLog: PR gdb/26905 * gdb.base/vla-optimized-out.exp: Add KFAILs for PR gdb/26905. * gdb.base/vla-ptr.exp: Likewise. --- gdb/testsuite/ChangeLog | 6 ++++++ gdb/testsuite/gdb.base/vla-optimized-out.exp | 8 +++++++- gdb/testsuite/gdb.base/vla-ptr.exp | 2 ++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.base/vla-optimized-out.exp b/gdb/testsuite/gdb.base/vla-optimized-out.exp index 203a82d..aaa6cd5 100644 --- a/gdb/testsuite/gdb.base/vla-optimized-out.exp +++ b/gdb/testsuite/gdb.base/vla-optimized-out.exp @@ -16,6 +16,7 @@ # Check whether we can determine the size of an optimized-out vla. standard_testfile +set using_clang [test_compiler_info clang*] # The EXE_SUFFIX is a string appended to the name of the test binary # to make it unique per variation. @@ -23,7 +24,7 @@ standard_testfile # flags used for building the test binary, and the second item is a # pattern which matches some expected output within this proc. proc vla_optimized_out {exe_suffix options} { - global testfile srcfile + global testfile srcfile using_clang lassign $options compile_flags sizeof_result @@ -37,10 +38,12 @@ proc vla_optimized_out {exe_suffix options} { return } + if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "p a" \ " = " \ "printed optimized out vla" + if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "p sizeof (a)" \ " = ($sizeof_result)" \ "printed size of optimized out vla" @@ -55,14 +58,17 @@ proc vla_optimized_out {exe_suffix options} { # been removed. As such GDB can't be expected to know if the # array contains _any_ elements at all. It seems reasonable in # that case to reply with 'no such vector element'. + if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "p a\[0\]" \ "(= |no such vector element)" \ "print out of range element of vla (0)" + if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "p a\[6\]" \ "no such vector element" \ "print out of range element of vla (6)" + if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "p a\[0xffffffff\]" \ "no such vector element" \ "print out of range element of vla (0xffffffff)" diff --git a/gdb/testsuite/gdb.base/vla-ptr.exp b/gdb/testsuite/gdb.base/vla-ptr.exp index 346ff00..adf1779 100644 --- a/gdb/testsuite/gdb.base/vla-ptr.exp +++ b/gdb/testsuite/gdb.base/vla-ptr.exp @@ -14,6 +14,7 @@ # along with this program. If not, see . standard_testfile +set using_clang [test_compiler_info clang*] if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } { return -1 @@ -38,4 +39,5 @@ gdb_test "print *vla_ptr" " = 2" "print *vla_ptr (bar)" gdb_breakpoint [gdb_get_line_number "vla_func_bp"] gdb_continue_to_breakpoint "vla_func_bp" +if {$using_clang} { setup_kfail "gdb/26905" *-*-* } gdb_test "print td_vla" " = \\\{4, 5, 6, 7, 8\\\}" -- 1.8.3.1