Re: [testsuite, rfa] Add gthreads dependency to some failing libstdc++ tests

[Jonathan Wakely <jwakely at redhat dot com>]

On 24/01/19 11:53 -0700, Sandra Loosemore wrote:
> On 1/24/19 3:46 AM, Jonathan Wakely wrote:
> > On 23/01/19 12:50 -0700, Sandra Loosemore wrote:
> > > I ran libstdc++ tests on nios2-elf target.  I observed several new 
> > > tests failing with
> > >
> > > error: 'mutex' in namespace 'std' does not name a type
> > >
> > > The definition of class mutex in include/bits/std_mutex.h is 
> > > guarded with "#ifdef _GLIBCXX_HAS_GTHREADS" so I assume these 
> > > tests are not supposed to work on this target.  This patch adds 
> > > the equivalent dependency to the failing tests.
> >
> > Those features *should* work without threads (if you don't have
> > multiple threads, they don't need any synchronisation), but currently
> > they use mutexes unconditionally.
> >
> > The proper fix is to make them work without gthreads, something like
> > https://gcc.gnu.org/ml/libstdc++/2018-12/msg00010.html
> >
> > > OK to commit?  (I guess it is possible that this is actually a bug 
> > > in the code instead, and the tests are supposed to pass....)
> >
> > I'd prefer to XFAIL them, so that we remember to un-XFAIL them if/when
> > I make them stop using mutexes. But we don't have a gthreads
> > effective-target that would allow that, only the dg-require-gthreads
> > directive.
> >
> > Also this patch will skip the tests on AIX, which could run these
> > tests if we added -pthread to the dg-options.
> >
> > But these features are half-baked and experimental, and not going to
> > get more changes in time for GCC 9, so OK for trunk.
>
> Well, if this testsuite patch would indeed be papering over a bug, I 
> think it's probably a bad idea to commit it.  For purposes of 
> nios2-elf testing I can just track these as known failures for now, 
> and not worry about them.

If that's OK with you (and David can live with the same situation on
AIX for a bit longer) then I'd prefer to leave them FAILing.

> BTW, I'm more worried about the link errors introduced by the patch 
> for PR 86756.  Those are regressions and apparently a problem that 
> could affect user code, not just broken test cases for half-baked new 
> features.

If I understand correctly(*) it can only affect user code that uses
the std::filesystem library, which was new in GCC 8.1, and if those
tests are failing for nios2-elf then it was never usable anyway. The
tests run by default now, but previously they were only run if gcc was
configured with --enable-libstdcxx-filesystem-ts, so this isn't really
a regression in what users can do with the library. I agree they're
more important than the experimental/net/ tests though.

(*) only a few of the 27_io/filesystem/path tests are showing these
linker errors, right? Or are tests outside 27_io/filesystem also
affected?