Description
Intel support is just about the only thing holding up version 2.6.2; there are now three open PRs on it. I've been working with Intel's support team, and they would like standalone examples of the bugs if possible. This helps track the progress, and is a call for standalone examples of the bugs.
PR 1: #2573: Initial support for “OneAPI” Intel compilers, using CI for the first time. (We’ve always supported older compilers, like 18 & 19, but had no CI and only tested C++11 - C++14 was actually C++11 due to a typo)
- arg()/arg{} transformation lifetime issue
- Submitted as intel bug 04916223 on https://supporttickets.intel.com
- Closed to due to no priority license
- Needs standalone example if possible
- Submitted as intel bug 04916223 on https://supporttickets.intel.com
- Using
Constructor() = default
is broken, we have to useConstructor {}
instead in several places. Also~Destructor() = default
, too.
PR 2: #2729: Builds / reimplements PR 1, from someone else, but also address new C++17 issues since we have never tested with C++17 on earlier compilers (14 either, actually, due to a typo):
- Intel complier can’t compile
enable_if_t<!all_of<is_positional<Args>...>::value>
- have to use workaround to define in multiple parts- Three times, one time was not too bad, but one of them really should have been possible to write inline. It really doesn’t like complex template arguments.
- Submitted as intel bug 04916230 on https://supporttickets.intel.com
- Closed to due to no priority license
- Needs standalone example if possible
- Weird warning had to be added: If you are encountering an 'error: name followed by "::" must be a class or namespace name’ with the Intel compiler and a noexcept function here, try to use noexcept(true) instead of plain noexcept.
- Includes a test change to compile
#if defined(__cpp_fold_expressions) && !defined(__INTEL_COMPILER)
Intel compiler produces an internal error on this fold expression (This was broken on ICC 19 too)- We have to add
<aligned_new>
to get ICC to follow the standard, but that seems to be a known compatibly issue
PR 3: #2769 Just opened yesterday to try icpx. The CI configs may have an issue there, it’s not running at all yet.
@ax3l @mkuron @tobiasleibner @YannickJadoul @bstaletic might be interested.
I'm thinking about adding a workaround def so that we can disable the workarounds at will, to see if they are still needed. That might be the best way forward for us without interfering with getting the problems fixed upstream.