| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This in effect means that cxx_relaxed_constexpr is now supported
by MSVC and Intel 18.0-18.04.
|
|
|
|
|
|
| |
Update the special case added by commit f719a13c28 (Features: Add
special case to disable relaxed constexpr for Intel 18, 2018-06-04,
v3.12.0-rc1~11^2) to record that 18.0.5 fixed the regression.
|
|
|
|
|
|
|
|
|
|
| |
Intel compilers define `__cpp_constexpr` to `200704` even in C++14 mode.
This indicates that the `cxx_relaxed_constexpr` feature is not
available. However, Intel 17 and above document support for it. In
commit v3.8.0~9^2 (Features: Update features for Intel C++ 17.0.2 on
UNIX, 2017-03-31) we added a special check for this case. Intel 17 and
19 work. However, Intel 18 does not seem to work and fails our test
case. Add a special case to disable the feature for Intel 18.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Features recorded by commit v3.6.0-rc1~120^2~5 (Features: Record
standards and features for Intel C++ on UNIX, 2016-04-28) for the Intel
compiler left out initializer list support because our test case in
`Tests/CompileFeatures/cxx_generalized_initializers.cpp` caused an
internal compiler error. It turns out this is because the Intel
compiler asserts the `initializer_list` constructor signatures to verify
that they match its own `<initializer_list>` header. It was our dummy
implementation used to test the language feature without any headers
that caused the ICE. Revise it to use a constructor signature accepted
by the Intel compiler.
Fixes: #17829
|
|
|
|
|
|
|
| |
Intel 17.0.2 on UNIX introduced a regression from 17.0.1 in its
definition of `__cpp_constexpr` in `-std=c++14` mode. It incorrectly
defines it as `200704` instead of the expected `201304`. Fix our
feature detection table to account for this.
|
|\
| |
| |
| |
| |
| | |
5e428389 Features: Detect Intel C++14 mode more reliably
1f848031 Features: Suppress c_static_assert test coverage on Intel <= 15
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `__cplusplus` macro is not defined to the language level reliably.
When simulating MSVC it is always set to `1`. When simulating GCC it is
set to the lower value of the current language level and the maximum
level supported by the simulated version of GCC (from observation).
For MSVC we already used a combination of `__INTEL_CXX11_MODE__` and
`__cpp_aggregate_nsdmi` to detect C++14 mode. Extend this for general
use by removing the condition on `_MSC_VER`.
|
|/
|
|
|
| |
The Intel 15 compiler for Windows does not support the same set of
standards and features as the same version for other platforms.
|
|
|
|
|
|
| |
This condition needs to follow the same pattern added in note `[1]` by
commit a5a3642f (Features: Port Intel CXX features to test macros where
possible, 2016-10-26). It was accidentally left out of that commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this compiler always defines `__cplusplus` to `1` we need to use
`_MSC_VER`, `__INTEL_CXX11_MODE__`, and the feature test macro named
`__cpp_aggregate_nsdmi` to detect C++11 and C++14 modes.
With no `-Qstd=` flag this compiler defaults to C++98 plus a subset of
C++11/C++14 features needed to be compatible with MSVC. We pretend it
is plain C++98 and add a `-Qstd=` flag whenever needed for C++11 or
above features even if they would happen to be available in MSVC-mode.
Closes: #16384
|
|
|
|
|
|
| |
The Intel 16 and 17 compilers define feature test macros of the form
`__cpp_<feature>`. Use them where possible to detect corresponding
features.
|
| |
|
|
|
|
| |
Issue: #16384
|
|
|
|
|
|
| |
Versions below 12.1 do not provide enough information to properly detect
if compiling with c++98 or c++0x enabled so remove them from the
supported list.
|
|
Skip this for now on Windows (where Intel C++ simulates MSVC).
|