Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.80%. Comparing base (acef5a9) to head (d436118).
Report is 2744 commits behind head on master.

@@            Coverage Diff             @@
##           master    #9850      +/-   ##
==========================================
- Coverage   67.80%   67.80%   -0.01%     
==========================================
  Files         400      400              
  Lines       85522    85522              
  Branches    18825    18825              
==========================================
- Hits        57987    57986       -1     
- Misses      23035    23036       +1     
  Partials     4500     4500              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Just a note that this PR is the output of the longer discussion on issue #8113, and the code-change workings is described in #8113 (comment).

Merging this PR will enable Meson to correctly detect and use the OneAPI compiler.

As this is new functionality it should have a release note snippet.

Isn't this going to result in using th eIntel compiler with an Id as clang? Even if it uses clang under the hood, there are still some differences right, enough to justify having at least a unique name like "oneAPI" or "Intel DPC" or something (just not intel or intel-cl)?

I think a new ID is called for (CMake gives it IntelLLVM, but oneapi or intel-oneapi is probably fine). As a concrete use case, the Intel OneAPI compiler has some…interesting decisions around some flag defaults that projects probably want to be able to detect it specifically (of note, -fp-model=precise is needed to remove -ffast-math-like behaviors on -O1 and above).

That's... interesting. And means that the implementation in Meson needs to override the optimization levels as well, so that we add -fp-mode=precise to the arguments by default

I think a new ID is called for (CMake gives it IntelLLVM,

This is what gh-10909 does. So that probably supercedes this PR.

It adds a new class, but doesn't override anything such as the ID.

It is the right approach, just not all the way there. :)

Just noting that this hasn't been touched in 2 years, and it'd be really nice to have!

@aaronsuydam #10909 implements this, and has been landed for almost 2 years. The only think I see here that we don't have upstream is the note about the -fp-model=precise. Since the intention of this is already upstream, I'm going to close this.

@dcbaker ah ok great. There's nothing in the web docs about this having been implemented (that I saw), what's the meson.build option I need to use? Haven't been able to get it to work.

@aaronsuydam there isn't a meson.build option. It is supporting a new compiler and compilers are defined in the toolchain ("machine") file or inferred by setting the environment variables CC and CXX.

The meson docs include a reference table listing supported compilers alongside the ID return values for checking inside meson.build "which compiler is this build directory + toolchain configured to use".

intel-llvm --> Intel oneAPI LLVM-based compiler

It's also mentioned in the release notes for meson 0.64.0