Re: RFA: Don't include value of expression in pc-fp.exp test name

[Michael Elizabeth Chastain <mec at shout dot net>]

Hi Andrew,

ac> It is very important when an issue such as this re-emerges that all 
ac> parties openly and transparently recognize there are differing opinions 
ac> - "I think ..., but note that previously this wasn't resolved" - always 
ac> be willing to raise the red flag so to speak.

Yes.  We are both here because we love the same things.
I've been thinking for the past two days "the point is to work
with Andrew, but my e-mail comes out like I'm fighting him,
argh."

ac> The testsuite contains plenty of cases where the approach of putting 
ac> suplemental information in paren has been used. "(timeout)" being the 
ac> most obvious example.

Okay, suppose there are results for the same test from two different
test runs.

  gdb.foo/bar.exp: PASS: frotz frotz frotz
  gdb.foo/bar.exp: FAIL: frotz frotz frotz (timeout)

With your analyzer tool, your report shows one test name with
two different results:

  frotz frotz frotz            PASS  FAIL

With my analyzer tool, my report shows two different test names:

  frotz frotz frotz            PASS
  frotz frotz frotz (timeout)        FAIL

This is slightly incorrect.

So I agree, it is nice to have an invariant test name with
supplemental information.

Now here's another case:

  gdb.base/cvexpr.exp: (const char)
  gdb.base/cvexpr.exp: (const signed char)
  gdb.base/cvexpr.exp: (const unsigned char)
  gdb.base/cvexpr.exp: (const short)
  gdb.base/cvexpr.exp: (const signed short)
  gdb.base/cvexpr.exp: (const unsigned short)

Your analyzer tool makes a mess of this, but my analyzer tool
understands this perfectly.

ac> Now we're getting somewhere.  You've suggested /\/\/.*$/ as an 
ac> alternative pattern.  Are there guidelines in the dejagnu doco?

I looked, but I didn't find any.

I think we are breaking new ground here.

Michael C