Hi!

If that's of any help to document the version dependencies:

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.

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'.

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


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?


Grüße
 Thomas

Reply via email to