Message ID | 20221128125751.1712-1-tdevries@suse.de |
---|---|
State | Committed |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> 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 1AA3D385B1A5 for <patchwork@sourceware.org>; Mon, 28 Nov 2022 12:58:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AA3D385B1A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669640296; bh=0V18FHAtVLgSWrW4SrdWjr6q0c51i5nsujpstaDAIrU=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=M3ys9kj9fo9BM2mwerEjwsYHAEEGxtu5rqTloqTXvs3N8z2ONtuD56jeRWMaq21V2 XCxMLTD/thx7aMTXZ8sgnUro7EXl7cVyRyo04bd6HPQvyVnIem/lJ8VFM/xebJLIIA ZSsSB0sLFRf+slIZJtwY8SEEVOj5CTJRN2qajoi8= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id BC6E23858C62 for <gdb-patches@sourceware.org>; Mon, 28 Nov 2022 12:57:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC6E23858C62 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 0226C21B1E; Mon, 28 Nov 2022 12:57:52 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D7AFF13273; Mon, 28 Nov 2022 12:57:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SzdzM0+whGNocgAAMHmgww (envelope-from <tdevries@suse.de>); Mon, 28 Nov 2022 12:57:51 +0000 To: gdb-patches@sourceware.org Cc: Carl Love <cel@us.ibm.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com> Subject: [pushed] [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5 Date: Mon, 28 Nov 2022 13:57:51 +0100 Message-Id: <20221128125751.1712-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Tom de Vries <tdevries@suse.de> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[pushed,gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5
|
|
Commit Message
Tom de Vries
Nov. 28, 2022, 12:57 p.m. UTC
On powerpc64le-linux, using gcc 4.8.5, I run into: ... (gdb) PASS: gdb.arch/altivec-regs.exp: next (1) next^M 11 c = vec_add (a, b);^M (gdb) PASS: gdb.arch/altivec-regs.exp: next (2) print/x a^M $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a ... Looking at the disassembly and the debug info, it's clear why there's a FAIL. The debug info says that the variable can be found at some stack location, but the instructions don't seem to be writing there. We can work around this by marking variable a volatile. Likewise for b. Note that marking the variables as volatile doesn't change the location information. Tested on power64le-linux. --- gdb/testsuite/gdb.arch/altivec-regs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5
Comments
Tom: On Mon, 2022-11-28 at 13:57 +0100, Tom de Vries wrote: > On powerpc64le-linux, using gcc 4.8.5, I run into: > ... > (gdb) PASS: gdb.arch/altivec-regs.exp: next (1) > next^M > 11 c = vec_add (a, b);^M > (gdb) PASS: gdb.arch/altivec-regs.exp: next (2) > print/x a^M > $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M > (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a > ... > > Looking at the disassembly and the debug info, it's clear why there's > a FAIL. > > The debug info says that the variable can be found at some stack > location, but > the instructions don't seem to be writing there. > > We can work around this by marking variable a volatile. Likewise for > b. > > Note that marking the variables as volatile doesn't change the > location > information. > > Tested on power64le-linux. > --- > gdb/testsuite/gdb.arch/altivec-regs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c > b/gdb/testsuite/gdb.arch/altivec-regs.c > index 4d4fe3f5dbb..8f3b729fe3f 100644 > --- a/gdb/testsuite/gdb.arch/altivec-regs.c > +++ b/gdb/testsuite/gdb.arch/altivec-regs.c > @@ -2,7 +2,7 @@ > #include <stdio.h> > > vector unsigned int > -vector_fun (vector unsigned int a, vector unsigned int b) > +vector_fun (volatile vector unsigned int a, volatile vector unsigned > int b) > { > vector unsigned int c; > a = ((vector unsigned int) vec_splat_u8(2)); > > base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5 I ran this test case before and after your commit on my Power 10 and my Power 9 box. I did not see a failure before or after the commit on either machine. The fix looks fine to me as it doesn't change the behavior on Power 9 or Power 10 that I can see. Carl
On 11/28/22 18:02, Carl Love wrote: > Tom: > > On Mon, 2022-11-28 at 13:57 +0100, Tom de Vries wrote: >> On powerpc64le-linux, using gcc 4.8.5, I run into: >> ... >> (gdb) PASS: gdb.arch/altivec-regs.exp: next (1) >> next^M >> 11 c = vec_add (a, b);^M >> (gdb) PASS: gdb.arch/altivec-regs.exp: next (2) >> print/x a^M >> $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M >> (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a >> ... >> >> Looking at the disassembly and the debug info, it's clear why there's >> a FAIL. >> >> The debug info says that the variable can be found at some stack >> location, but >> the instructions don't seem to be writing there. >> >> We can work around this by marking variable a volatile. Likewise for >> b. >> >> Note that marking the variables as volatile doesn't change the >> location >> information. >> >> Tested on power64le-linux. >> --- >> gdb/testsuite/gdb.arch/altivec-regs.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c >> b/gdb/testsuite/gdb.arch/altivec-regs.c >> index 4d4fe3f5dbb..8f3b729fe3f 100644 >> --- a/gdb/testsuite/gdb.arch/altivec-regs.c >> +++ b/gdb/testsuite/gdb.arch/altivec-regs.c >> @@ -2,7 +2,7 @@ >> #include <stdio.h> >> >> vector unsigned int >> -vector_fun (vector unsigned int a, vector unsigned int b) >> +vector_fun (volatile vector unsigned int a, volatile vector unsigned >> int b) >> { >> vector unsigned int c; >> a = ((vector unsigned int) vec_splat_u8(2)); >> >> base-commit: 2650ea9730e31fc5c9111afc1a689dbca76707f5 > > I ran this test case before and after your commit on my Power 10 and my > Power 9 box. I did not see a failure before or after the commit on > either machine. The fix looks fine to me as it doesn't change the > behavior on Power 9 or Power 10 that I can see. Hi Carl, thanks for confirming, good to know. - Tom
diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c b/gdb/testsuite/gdb.arch/altivec-regs.c index 4d4fe3f5dbb..8f3b729fe3f 100644 --- a/gdb/testsuite/gdb.arch/altivec-regs.c +++ b/gdb/testsuite/gdb.arch/altivec-regs.c @@ -2,7 +2,7 @@ #include <stdio.h> vector unsigned int -vector_fun (vector unsigned int a, vector unsigned int b) +vector_fun (volatile vector unsigned int a, volatile vector unsigned int b) { vector unsigned int c; a = ((vector unsigned int) vec_splat_u8(2));