On 01/28/15 15:16, Rainer Orth wrote:
Jakub Jelinek <ja...@redhat.com> writes:

On Wed, Jan 28, 2015 at 01:42:47PM -0700, Jeff Law wrote:
2015-01-28  Rainer Orth  <r...@cebitec.uni-bielefeld.de>

        gcc/testsuite:
        * gcc.dg/guality/guality.h (main): Add argv[0] to
        guality_gdb_command.
OK.

As for what to do with guality, I haven't a clue.  They're dependent on the
debugger version and perhaps other stuff that I don't recall.

Perhaps skip them if we find gdb and determine it is "too old"?

We already do that.  I bet the Solaris case is more about the lack
of support to find an executable from its pid (/proc/<pid>/exe
in Linux).
Guess one can easily try it, run
gdb
(without arguments, or those -nx -nw that guality uses) and type
attach 19355 # pick pid of some process you can debug
in Linux gdb will find the binary etc.

That issue is easily solved by passing the executable name to gdb; this
is guaranteed to work everywhere.  On Solaris (at least from Solaris 10
onwards, haven't checked earlier version), gdb could use
/proc/<pid>/path/a.out to get at the executable, but that won't help for
released versions of gdb (and eventually other platforms which provide
no such facility).

But this issue is minor and easily avoided.  The major problem is that
on both Solaris and Linux, many of the guality tests FAIL (or XPASS,
equally adding noise to mail-reports.log) even with a current version of
gdb (7.8 in my case):


                                 Linux/x86_64   Solaris 11/x86  Solaris 11/SPARC
                                 (Fedora 20)

gcc.dg/guality:

# of expected passes            6490            6500            5489
# of unexpected failures        191             171             802
# of unexpected successes       61              66              73
# of expected failures          35              30              23
# of unsupported tests          257             267             383

g++.dg/guality:

# of expected passes            128             128             118
# of unexpected failures        6               10              10
# of unsupported tests          34              30              40
Could we select a version of gdb as a reference version, then xfail those tests which don't work with that reference version on each platform to cut down the noise? Obviously we bump the reference version, probably as we close stage1 or stage3 development?

It's not unusual to have different test results across x86 vs x86_64 vs sparc. What I'd be real interested to know is if x86 across linux and solaris give the same results, similarly for x86-64 across those two platforms.


I realize it's a fair amount of work, but I'm always reluctant to simply disable a large number of tests.

Jeff

Reply via email to