From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25436 invoked by alias); 23 May 2011 10:27:36 -0000 Received: (qmail 25424 invoked by uid 22791); 23 May 2011 10:27:35 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 May 2011 10:27:21 +0000 Received: (qmail 1730 invoked from network); 23 May 2011 10:27:20 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2011 10:27:20 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [_Complex test 2/4] _Complex type in varargs.exp Date: Mon, 23 May 2011 10:27:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Yao Qi , "Joseph S. Myers" References: <4DC401D0.1050500@codesourcery.com> <201105201637.19106.pedro@codesourcery.com> <4DD9DDDA.9030602@codesourcery.com> In-Reply-To: <4DD9DDDA.9030602@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105231127.17868.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00511.txt.bz2 On Monday 23 May 2011 05:08:58, Yao Qi wrote: > On 05/20/2011 11:37 PM, Pedro Alves wrote: > > Did you try setup_kfail? See below. The way you have things > > doesn't catch the internal error case because that is matched > > within gdb_test_multiple itself. You could also check the return > > of gdb_test_multiple to see if an internal match happened, but > > that's more complicated than setup_kfail. > > > > I see. It has been mentioned in the comment to proc gdb_test_multiple > > # Returns: > # 1 if the test failed, according to a built-in failure pattern > # 0 if only user-supplied patterns matched > # -1 if there was an internal error. > > Thanks. > > >> > x86_64-unknown-linux-gnu: > >> > KFAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, > >> > fc4) (PRMS: gdb/12790) > >> > KFAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, > >> > dc3, dc4) (PRMS: gdb/12790) > >> > FAIL: gdb.base/varargs.exp: print find_max_long_double_real(4, ldc1, > >> > ldc2, ldc3, ldc4) (GDB internal error) > >> > > > setup_kfail gdb/12776 "i?86-*-*" > > setup_kfail gdb/12790 "x86_64-*-*" > > setup_kfail gdb/12791 "arm*-*-*" > > set test "print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)" > > gdb_test_multiple $test $test { > > -re ".*= 4 \\+ 4 \\* I.*${gdb_prompt} $" { > > pass $test > > } > > } > > This is exactly what I did when I was writing this patch. However, the > wrong PR number is got in KFAIL result, like this, > > KFAIL: gdb.base/varargs.exp: print find_max_long_double_real(4, ldc1, > ldc2, ldc3, ldc4) (PRMS: gdb/12791) > > I was running test case on i686-pc-linux-gnu, but the PR number > displayed was arm's PR. Source code of proc setup_kfail shows that PR > number is saved in kfail_prms unconditionally. Of course, only the PR > in last call of setup_kfail is saved. This is a limitation of > setup_kfail, IMO. Huh, indeed. > I gave up on this direction then. > > In order to overcome this limitation, a new proc setup_kfail_for_target > is added in lib/gdb.exp, which only call setup_kfail if istarget returns > true. Okay. > > > Maybe you can even convert the gdb_test_multiple's to gdb_test that way. > > (You could also put the setup_kfails in a procedure to not need to > > repeat them everywhere). > > Since we are using setup_kfail, we can surely convert gdb_test_multiple > to gdb_test. I don't put setup_kfails in a proc, because, KFAILs on x86 > are different from KFAILs on arm/x86_64. > > In my new patch, the internal-error on x86_64 is KFAIL'ed. > > KFAIL: gdb.base/varargs.exp: print find_max_long_double_real(4, ldc1, > ldc2, ldc3, ldc4) (GDB internal error) (PRMS: gdb/12790) Looks good to me. -- Pedro Alves