From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15964 invoked by alias); 3 Jul 2007 00:05:20 -0000 Received: (qmail 15956 invoked by uid 22791); 3 Jul 2007 00:05:19 -0000 X-Spam-Check-By: sourceware.org Received: from a.mail.sonic.net (HELO a.mail.sonic.net) (64.142.16.245) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jul 2007 00:05:17 +0000 Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l6305CKV005813; Mon, 2 Jul 2007 17:05:12 -0700 Received: from 12.7.175.2 (SquirrelMail authenticated user msnyder) by webmail.sonic.net with HTTP; Mon, 2 Jul 2007 17:05:12 -0700 (PDT) Message-ID: <9624.12.7.175.2.1183421112.squirrel@webmail.sonic.net> In-Reply-To: <20070701160224.GH10872@caradoc.them.org> References: <16087.12.7.175.2.1183076995.squirrel@webmail.sonic.net> <20070701154831.GE10872@caradoc.them.org> <004a01c7bbf8$16a2ccc0$677ba8c0@sonic.net> <20070701160224.GH10872@caradoc.them.org> Date: Tue, 03 Jul 2007 00:05:00 -0000 Subject: Re: [RFC] logic change in m2-valprint.c From: msnyder@sonic.net To: gdb-patches@sourceware.org, gaius@glam.ac.uk User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: 2007-07/txt/msg00042.txt.bz2 > On Sun, Jul 01, 2007 at 08:54:19AM -0700, Michael Snyder wrote: >> > It can't be backwards; this is trying to print "1" or "1, 2" but your >> > change would make it print ", 1" and ", 12". >> > >> > I think it's also trying to shorten ranges to "{1..3, 6..7}". The >> > bug's got to be in there somewhere. Why's the code dead? I'm not >> > seeing it... element_seen can be reset by the bit clear case, and then >> > we'll get into the test you're changing again. >> >> 'Cause we're not in a loop, and it's not a static variable. >> The code is serial. At entry we set empty_set to one, and >> then we test to see if it's zero. It can't be zero. > > How sure are you sure we're not in a loop? :-) I'm sorry -- too many balls in the air. Try this: 91 int empty_set = 1; 92 int element_seen = 0; ... 123 for (i = low_bound; i <= high_bound; i++) ... 133 if (! element_seen) 134 { 135 if (! empty_set) 136 fprintf_filtered (stream, ", "); 137 print_type_scalar (target, i, stream); 138 empty_set = 0; 139 element_seen = 1; 140 previous_low = i; 141 } So, the reasoning is as follows: line 136 is dead code, because line 135 can never test true, because the first time we enter the block beginning at line 133, empty_set will be true (there is nowhere else for it to be set false), and there is no second time -- we will never enter this block again because we will set "element_seen" to true (and there is nowhere else for it to be set false again). Was that clear? So on pass "n", we enter the block. Empty_set must be true. We now set empty set false, and element_seen to true, and therefore on pass "n + m" we cannot enter the block. So there is no point at which we can execute line 136.