On 27/03/19 15:51 +0100, Thomas Schwinge wrote:
Hi!
If that's of any help to document the version dependencies:
Thanks for t his.
On Fri, 22 Mar 2019 00:04:30 +0000, Jonathan Wakely <jwak...@redhat.com> wrote:
I keep forgetting to add that docs for this stuff will be coming some
time next week, describing the TBB dependency that's needed to use
these parallel algos.
On an Ubuntu 12.10 x86_64 GNU/Linux system (yes, a bit old by now), I saw
all these test UNSUPPORTED.
I then installed 'libtbb-dev' (and the implied 'libtbb2'; both version
4.0+r233-1), and then saw all? tests FAIL because of:
[...]/libstdc++-v3/include/pstl/parallel_backend_tbb.h:25: fatal error:
tbb/task_arena.h: No such file or directory
I then manually installed the Ubuntu trusty (14.04LTS) version
4.2~20130725-1.1ubuntu1 packages, and then saw all? tests FAIL because
of:
[...]/libstdc++-v3/include/pstl/parallel_backend_tbb.h:29: error: #error
Intel(R) Threading Building Blocks 2018 is required; older versions are not
supported.
Yes, that's a known dependency.
Tom, I think check_effective_target_tbb-backend should probably check
the TBB_VERSION_MAJOR macro in <tbb/tbb_stddef.h> and fail if an
older version is detected.
That will only help when running our tests though, not when users try
to use the algos, so we probably need to fail more gracefully if the
user has an odler TBB installed. If there's a header which is present
in TBB-2018 but not older versions then <bits/c++config.h> could check
for that instead of (or as well as) <tbb/tbb.h>.
So I suppose I need the most recent Ubuntu disco version 2018~U6-4
packages. Because of:
dpkg-deb: error: archive 'libtbb-dev_2018~U6-4_amd64.deb' contains not
understood data member control.tar.xz, giving up
..., I manually had to convert to '*.gz' files the'.xz' files inside of
these '*.deb' archives, which yet still failed to install:
dpkg: dependency problems prevent configuration of libtbb2:amd64:
libtbb2:amd64 depends on libstdc++6 (>= 7); however:
Version of libstdc++6:amd64 on system is 4.7.2-2ubuntu1.
..., which isn't really a problem as I'll obviously be testing against a
new-enough GCC/libstdc++ ;-) -- so, installed these packages with
'--force-depends-version'.
With that, the tests then all PASS for the default multilib, but all?
FAIL for '-m32' testing:
[...]/ld: cannot find -ltbb
There is no 32-bit 'libtbb' available. I suppose the problem is that
'check_effective_target_tbb-backend' just does a 'preprocess' test
checking for existence of '<tbb/tbb.h>', but doesn't actually try to
link, whereas all? the test cases specify '-ltbb' via 'dg-options'.
Right. Jakub noticed the same issue.
That said, instead of specifying:
// { dg-options "-std=gnu++17 -ltbb" }
// { dg-do run { target c++17 } }
// { dg-require-effective-target tbb-backend }
... in all? these test case files, isn't there some DejaGnu directive
that checks whether support is available (else UNSUPPORTED), while also
adding the necessary compiler options (here: '-ltbb')?
I don't think we can do that in one go, can we?
We can add something so { dg-add-options tbb } adds the required
options, but I don't think it will make it UNSUPPORTED when necessary.
Maybe I'm missing something.
Also, shouldn't 'check_effective_target_tbb-backend' (and also some of
the other checks in 'libstdc++-v3/testsuite/lib/libstdc++.exp'?) be using
'check_v3_target_prop_cached' to avoid checking the same things again and
again?
Yes. I think it was probably written before that caching helper was
added.
