Portability fixes to compile with XCode / libc++
- Add
Dune::PDELab::Execution
execution policies- Internally use PSTL if available or
oneapi::dpl
as fallback
- Internally use PSTL if available or
- Ensure
std::format
is available before use (empty header exists in some libc++ versions) - If
std::atomic_ref
is not available fall back toboost::atomic_ref
if available, otherwise throw at runtime - Add typename where needed
- Add
&
to fix "cannot overload a member function without a ref-qualifier with a member function with ref-qualifier" -
consteval
->constexpr
("call to consteval function is not a constant expression" error: probably a compiler bug in appleclang) - Ensure moved-from
std::function
is empty- after being moved from it is only guaranteed to be in a valid but unspecified state, not necessarily empty
- for gcc/clang implementations it is empty, but apparently not for appleclang
- Always use
forward_range
forSparseDynamicRange
/DenseDynamicRange
- they don't fulfill the requirements for
tbb::blocked_range
- (a requires expression that constructs a
tbb::blocked_range
nonethless returnsTrue
on appleclang, only for compilation to fail later)
- they don't fulfill the requirements for
- Avoid calling constructors without all arguments (c++20 feature not yet supported by appleclang)
Merge request reports
Activity
requested review from @santiago.ospina
Thanks a lot, that's a huge clean up! Very much appreciated :)
Always use
forward_range
forSparseDynamicRange
/DenseDynamicRange
- they don't fulfill the requirements for
tbb::blocked_range
- (a requires expression that constructs a
tbb::blocked_range
nonethless returnsTrue
on appleclang, only for compilation to fail later)
This branching between
tbb::blocked_range
andforward_range
was mainly done because grid iterators are only forward iterators and it kind of payed off to have a custom iterator. This is from my early tests with multi-threaded assembly. Other containers were supposed to go to native tbb case. Moreover, with the new grid partitions for concurrency that are introduced in the multi-threaded branch the parallel loop over the entities is done over random access iterators and hence these forward blocked ranges are (in theory) not needed anymore. So I am curious what error did you get with theSparseDynamicRange
/DenseDynamicRange
ranges? Looking at the implementation again, I think that they should work okey for random access iterators too so I am also fine with leave them if that's what works.- they don't fulfill the requirements for
mentioned in commit 9eff7caa
mentioned in merge request copasi/dune-copasi!108 (merged)
If I remember correctly I got compilation errors where
tbb::blocked_range
would be used on mac and give compiler errors that the dune forward iterator type doesn't have a<
operator - but I haven't been able to find the CI logs. I can try to reproduce it (I don't remember if this was with llvm clang or appleclang).I agree that once you merge your branch with random access instead of forward iterators, removing
forward_range
and just usingtbb::blocked_range
would be the best solution.- Resolved by Santiago Ospina De Los Ríos
I tried reverting the blocked_range change:
liam.keegan/dune-pdelab@d22715f2
Gives this compile error on linux & mac:
In file included from /opt/smelibs/include/dune/pdelab/common/for_each.hh:13: In file included from /opt/smelibs/include/oneapi/tbb/parallel_for.h:28: /opt/smelibs/include/oneapi/tbb/blocked_range.h:82:43: error: invalid operands to binary expression ('const Dune::Imp::compressed_base_array_unmanaged<double>::RealIterator<double>' and 'const Dune::Imp::compressed_base_array_unmanaged<double>::RealIterator<double>') 82 | bool empty() const { return !(my_begin<my_end); }
Full CI logs: https://github.com/spatial-model-editor/sme_deps/actions/runs/6863894893