From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24956 invoked by alias); 11 Nov 2004 20:09:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24593 invoked from network); 11 Nov 2004 20:09:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Nov 2004 20:09:14 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iABK9B2b006771 for ; Thu, 11 Nov 2004 15:09:12 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iABK9Ar09016; Thu, 11 Nov 2004 15:09:10 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D9D43129D8C; Thu, 11 Nov 2004 15:07:59 -0500 (EST) Message-ID: <4193C69E.9050403@gnu.org> Date: Thu, 11 Nov 2004 20:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Some testcases for long long bitfields References: <20041101113842.511BDF2B98@nile.gnat.com> In-Reply-To: <20041101113842.511BDF2B98@nile.gnat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00242.txt.bz2 Here we go :-) - which system was it tested on? - loose this: > +# Please email any bugs, comments, and/or additions to this file to: > +# bug-gdb@prep.ai.mit.edu - reword the tests from: > "bitfield uniqueness (u1)" to something like: bitfield uniqueness; flags.u1 = 1 so that what's being tested is clearer and the names are unique. - on similar lines, take the gdb.sum file from running this testand put it through 'uniq -d' s.fixing any duplicate - use gdb_test_multiple > + # Determine if the target has signed bitfields so we can xfail the > + # the signed bitfield tests if it doesn't. > + set no_signed 1 > + send_gdb "print i\n" > + gdb_expect { > + -re ".* = -32768.*$gdb_prompt $" { > + set no_signed 0 > + pass "determining signed-ness of bitfields" > + } - Why? Or is this really a known bug? > + if $no_signed then { > + setup_xfail "*-*-*" > + } > + set test "set long long signed bitfield negative" > + gdb_test_multiple "print flags.s2 = -1" $test { > + -re "warning: Value does not fit.*$gdb_prompt $" { > + fail "$test" > + gdb_suppress_tests > + } > + -re "= -1.*$gdb_prompt $" { > + pass "$test" > + } > + } - ditto? > + if $no_signed then { > + setup_xfail "*-*-*" > + } > + if [gdb_test "print flags" "u1 = 0, u2 = 4294967296, u3 = 0, s1 = 0, s2 = -1, s3 = 0.*" "long long bitfield values after set negative"] { > + gdb_suppress_tests > + } > + gdb_stop_suppressing_tests; > +} > +bitfield_uniqueness - delete this: > +if [istarget "mips-idt-*"] then { > + # Restart because IDT/SIM runs out of file descriptors. > + gdb_exit > + gdb_start > + gdb_reinitialize_dir $srcdir/$subdir > + gdb_load ${binfile} > +} - for all these: + if { ! [runto break5] } { + gdb_suppress_tests + } perhaphs think about what I did for the sig*.exp tests - have main as a loop so that it looped around after each test sequence was finished - will on remote systems improve the performance somewhat. But what ever. Once all this are addressed, post the update _along_ with the system tested on, and then it can be committed. Andrew