Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] delete gdb.cp/ambiguous.exp ?
Date: Tue, 19 Aug 2014 17:50:00 -0000	[thread overview]
Message-ID: <53F38E62.60403@redhat.com> (raw)
In-Reply-To: <CADPb22TNGVOJ-WM9dQ5z_KetULps7ZfnXBG5DkxPOYTR00D8cw@mail.gmail.com>

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.  ;-)

> 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.  ;-)  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.

Thanks,
Pedro Alves


  reply	other threads:[~2014-08-19 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18 23:23 Doug Evans
2014-08-19  6:58 ` Joel Brobecker
2014-08-19 16:49 ` Pedro Alves
2014-08-19 17:25   ` Doug Evans
2014-08-19 17:50     ` Pedro Alves [this message]
2014-08-19 20:10       ` Doug Evans
2014-08-19 21:47         ` Pedro Alves
2014-08-22 20:07           ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F38E62.60403@redhat.com \
    --to=palves@redhat.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox