Jonathan Wakely writes:
> 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.
>
Ok, I'll look at adding that check.
> 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>.
>
Yes the TBB-2018 is a hard dependency in the Intel backend, but I can
likely make this more graceful. There is also a serial 'fallback' backend
currently in the works in the upstream, which would at least give
something to fallback to here.
>
>>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.
