alpaka: std::decay_t causes internal compiler errors in Intel compiler
In TaskKernelCpuOmp2Blocks.hpp the lines 102 and 122 read
[this](typename std::decay<TArgs>::type const & ... args)
The std::decay in these lines produces an internal compiler in all Intel.2018 versions. In alpaka 0.3.5 these lines (there in ExecCpuOmp2Blocks.hpp) just read
[this](TArgs const & ... args)
Unfortunatly we can’t switch to Intel.2019 or a newer version yet (since this causes other internal compiler errors in our code). However, if I just remove the std::decay in alpaka 0.4.1 I get a bunch of compilation errors. What is this std::decay for? If I want to remove it, what other changes do I need to make?
This is somehow related to #843
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 21 (18 by maintainers)
Commits related to this issue
- Simplify parameter deduction in TaskKernel... implementations with auto This is only done when the parameters were already of the correct (decayed) types, as stored in the m_args tuple. This also wor... — committed to sbastrakov/alpaka by sbastrakov 4 years ago
- Work around Intel ICE when using std::decay on empty template parameter packs Fixes #995 — committed to sbastrakov/alpaka by sbastrakov 4 years ago
- Work around Intel ICE when using std::decay on empty template parameter packs Fixes #995 — committed to alpaka-group/alpaka by sbastrakov 4 years ago
- Replace ALPAKA_DECAY_T by std::decay_t This feature was introduced as a workaround to a bug in the Intel classic compiler (see #995). Alpaka no longer supports that compiler, so the workaround is no ... — committed to bernhardmgruber/alpaka by bernhardmgruber 10 months ago
- Replace ALPAKA_DECAY_T by std::decay_t This feature was introduced as a workaround to a bug in the Intel classic compiler (see #995). Alpaka no longer supports that compiler, so the workaround is no ... — committed to alpaka-group/alpaka by bernhardmgruber 10 months ago
As a follow-up, you might want to add ICX/ICPX support to CI.
ICX/ICPX is the next-gen Intel compiler based on LLVM, it’s similar to the host-side of DPC++ and where new developments go. Here is a template to derive from: https://github.com/ECP-WarpX/WarpX/blob/0c8d5f61d92309b9a3df6e985f1a9d3da5edfd96/.github/workflows/ubuntu.yml#L81-L117 (apt lines) Note this bug shipped in the latest oneAPI and fixed in CMake
master
.Doesn’t work, same error. A documentation on how to build examples and tests would be good.
Same here, try to open it in “private mode” of your browser.
In parallel: reported as intel bug 04727055 at https://supporttickets.intel.com (had moderate success with those recently, but an ICE is a good thing to report.) Always open vendor issues, everyone!
I also added a PR drafting CI, as soon as the bug herein is fixed: #1066
@sbastrakov good luck today with this! 🤞
With @psychocoderHPC we narrowed it down, and it seems the Intel internal compiler error occurs bacause of
std::decay
with empty template pack. (So as was complained about originally). I will try to wrap it up in a special decay that for Icc handles the empty pack specially and explicitly does nothing. But that may be on my next work day, Wednesday. Or if someone wants to try this suggestion, they are welcome. I just used the helloWorld example and Serial accelerator to reproduce the issue.This issue is getting serious now. There is no recent Intel compiler we can work with.
icpc 2017.8, 2018.1, 2018.3: working with alpaka 0.3.5, failing with alpaka 0.4.1 and alpaka 0.5.0. icpc 2019.2, 2020.1: working with alpaka 0.3.5 and 0.4.1, failing with alpaka 0.5.0.
We don’t know the exact reason, the error message is always the same:
…/src/Matrix/LinesHelper.cpp(211): internal error: assertion failed at: “shared/cfe/edgcpfe/lower_name.c”, line 9640 compilation aborted for …/src/Matrix/LinesHelper.cpp (code 4)
Sorry, that’s the whole message. But we can’t abandon icpc.
For documentation I like to link @ax3l 's comment that it is now possible to add
icc
to travis https://github.com/alpaka-group/alpaka/issues/493#issuecomment-622222393