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

[Jonathan Wakely]

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?