Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • CMake CMake
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4,105
    • Issues 4,105
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 16
    • Merge requests 16
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CMakeCMake
  • CMakeCMake
  • Issues
  • #18869
Closed
Open
Issue created Feb 01, 2019 by Roland Schulz@rolandschulzContributor

ICC compiler feature detection

ICC feature detection for relaxed_constexpr isn't consistent. Contrary to what the commit message of f719a13c says, ICC doesn't always set __cpp_constexpr to 200704. Instead it depends on the GCC version it emulates (the gcc found in path or provided by -gcc-name). If that GCC version is 4.8 or lower than __cpp_constexpr is 200704. This has the result that for cmake versions >= 3.12 for ICC 18 cxx_relaxed_constexpr is in CMAKE_CXX_COMPILE_FEATURES depending on which GCC is found. But for ICC 17 it doesn't depend on it (even though __cpp_constexpr does).

As far as I can find, what exactly the feature detection is supposed to be returning isn't well defined. It seems to be varying between:

  • Report whatever the compiler is reporting through feature test macros independent of whether it is true (e.g. because the compiler is emulating another compiler) or whether it is bug-free
  • Report based on some set of tests of the feature and exclude versions which have known bugs. Also include versions which have support even though they claim not to.

It seems rather strange to have the feature test depend on bugs in the implementation. Given that it is unlikely that any compiler has zero bugs in any one feature, if the criteria would be that a feature needs to be completely bugfree, cmake would need to report false for everything. On the other hand if the criteria depends on a few known bugs, than it is unlikely that this is representative of the usage of the feature by a given project.

I would be very surprised to learn that there are more bugs in the ICC 18 constexpr implementation than in the ICC 17 constexpr implementation (especially because the cmake version test doesn't even check for difference in patch versions which have a big impact on the number of bugs). It seems the only reason ICC 18 is excluded but ICC 17 isn't, is that ICC 18 happen to have had a bug which was triggered by the specific testcase used (which I can't find documented). But it seems very unlikely that that testcase is representative of usage of the feature by many users (otherwise the bug would have likely be resolved much quicker).

I think two things are needed:

  1. It should be documented what exactly the feature tests should report. Should it reflect whether the feature is fully implemented, whether the compiler claims support, or whether it is fully/partially bugfree.
  2. the ICC reporting should reflect that and the inconsistency between 17 and 18 should be resolved.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking