From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24083 invoked by alias); 19 Aug 2014 20:10:20 -0000 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 Received: (qmail 24062 invoked by uid 89); 19 Aug 2014 20:10:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f180.google.com Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 19 Aug 2014 20:10:17 +0000 Received: by mail-vc0-f180.google.com with SMTP id ij19so7854043vcb.25 for ; Tue, 19 Aug 2014 13:10:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AueMLvxsRwqPRE2wvvsIf3jxZ1rABqAmEtddp3iiDSQ=; b=jb8L2GQZb2A+w+b0lcyVCbvlRHLBj890IdcWEina53J4x2uaZBxsBHlumsa/PRhi3y Wn+h5YB+8OShAQwmt/ORBbxKGFB5zX1DLpf2Bl/24hE0jg5KwmbXIFQhWW9uNZ61kqZe U6GpDVYjfz1eDSekcoYGX5woi8I340ItqtPxnGbL9Lbh/8fzWAt3My7X0ovlh+pBbjSe fMiWfWPATakwFRZpO1W5NrMZPlRMIl+b9idYPmfAu8tlRBoUwpWSHh6razWRK4k0QIFj WR7yQtiUJZfUhh2vN0A1t4Q06V+2yASnGmXCnLT/glExIhoGCOAAVh022LhaL3IQ0xcM n9Vw== X-Gm-Message-State: ALoCoQlXCM7LdE2AhlJnu2el3TB1eabbTrv5hQDH8Ji7l43j+2pcaHIyGUzTCHGZYQQhRFIbQbEX MIME-Version: 1.0 X-Received: by 10.52.248.211 with SMTP id yo19mr2094749vdc.67.1408479014858; Tue, 19 Aug 2014 13:10:14 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Tue, 19 Aug 2014 13:10:14 -0700 (PDT) In-Reply-To: <53F38E62.60403@redhat.com> References: <53F38030.1020406@redhat.com> <53F38E62.60403@redhat.com> Date: Tue, 19 Aug 2014 20:10:00 -0000 Message-ID: Subject: Re: [RFC] delete gdb.cp/ambiguous.exp ? From: Doug Evans To: Pedro Alves Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00358.txt.bz2 On Tue, Aug 19, 2014 at 10:50 AM, Pedro Alves wrote: > On 08/19/2014 06:24 PM, Doug Evans wrote: > >>> Actually enabling the test (removing the skip, and adding >>> nowarnings), we see that indeed GDB outputs no warning: >> >> But given the early exit the test itself is never run. > > As I said, I removed that. ;-) I know (I thought that was obvious). If you want to actually check in its removal, we can have that discussion. >> And it's been this way since at least 2003 (commit 4d9eda44f), and >> longer (that commit just changed the style of the gcc test)! > > Yeah, this probably came in in the big HP merge, much > earlier than that. There was once a gdb.hp/ambiguous.exp, even, and > this probably got copied from that. > There was once a big > everything-goes-we-dont-have-time-to-clean-things-up-before-accepting HP > import/contribution, and bits may be skipped on GCC just because the > HP folks at the time didn't want to deal with it in their local fork. > >> I'm all for filing a bug and recording the test in the bug report. >> I'm even ok with keeping the test as is. >> The high order bit for me is exploring what the community wishes be >> done with this kind of "dead code". > > You're asking for a generic opinion, of the abstract "community", > while I think "case by case" generally applies. ;-) I'm asking people for their opinion on this case (and cases like it). If I call them a "community", which is what gdb@ and gdb-patches@ is to me, I don't see the problem. Removal of dead code is, in my experience here, *rarely* a case by case decision. [each case may have minor details that are different, but the high order bit is generally DELETE IT :-)] And yet this is a little different than an #if 0 in code, so I'm asking. We certainly want to document this issue in some way, but if we're just going to leave the test as is, not being run, and yet have to disable it for new compilers as they come along, then I think there's value in documenting the issue in a different way (e.g., bug reports are fine for this sort of thing). > My inclination for > tests is to first check whether there's something salvageable. If > someone wrote the test, it was probably important enough. If it's indeed > "dead code", then of I'd go for just removing it. I looked, and it seemed > to me that the test actually covers an aspect of printing that we don't > cover elsewhere, and actually reveals a bug. > So IMO, in this particular case, we should keep the test, remove the gcc check, > modernize and KFAIL it , and then have the bug fixed (if people agree it's > a bug). I'm of course not suggesting you do that all of yourself, but > since you asked, that's what I'd prefer see done in this case. This is feedback I can work with. Thanks. Going forward, as we discover bugs, are people ok with checking in a KFAIL'd test for a bug before the bug is fixed? "Just fix the bug." is the canonical response. And yet there are often higher priorities. How do we document the bug's existence so that it's not forgotten until someone has time to fix it? File a bug report, of course. Well, I file bug reports all the time, I certainly don't have time to fix all of them instead of filing the bug report. And if in reproducing the bug I'm 80% of the way there in writing the test, is it ok to at least finish and check in that part, even if I don't have time to fix the bug? Or, instead of allowing that, should we just "grandfather in", so to speak, all existing disabled tests, not allow new KFAIL'd ones, and migrate these existing tests to KFAIL if we don't have time to fix the bug?