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.
