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

[Jonathan Wakely]

On 24/01/19 20:20 +0000, Jonathan Wakely wrote:
>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.

But feel free to report them to Bugzilla so I can't pretend I don't
know about them ;-)

>>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?

Do you have any idea how to detect the root cause, i.e. chdir, getcwd
etc. being declared in the headers but not at link-time?
Cross-compilers can't do link tests to check for them.

I can easily make the library throw an exception if
std::filesystem::current_path() is called and getcwd isn't available,
as long as I can detect when it's not available.