@bryanwweber / @speth ... I think this is as far as I can go with reasonable effort.

I had a closer look at the failing tests, and believe the only reason were minor numerical differences between Intel MKL (?) calculations and what is used elsewhere. I loosened the tolerances for cxx-kinetics1(same 'looser' tolerance that is used in other tests), and skipped the verbose test VCS-LiSi-verbose for lack of better options (verbose output is generated from a different execution branch when equilibrating, resulting in a different log output).

One thing that I briefly looked at, but decided to leave for a later point is pch (precompiled headers), which had already been disabled. I realize that I am not familiar enough with scons to find the correct flags; as far as I was able to find out, scons should actually recognize and use the correct options for pch. But at least for icc I am stuck with a Warning #672: the command line options do not match those used when precompiled header file "src/pch/system.pchi" was created.

Beyond, I put in some rudimentary information related to Intel's new icx/icpx/ifx compilers. While cantera builds (even with pch!) things segfault during testing.

I had a half-finished mingw GH runner laying around, and just gave it another shot - as it appears to work, I am adding it here.

@gkogekar ... interestingly, one of the solveCubic tests failed: see band-aid in commit d8b3fc8. If I interpret this correctly, a different root is found for mingw which may or may not create issues for PengRobinson.

Ad icc/icpc: changing the Wcheck (perform compile-time code checking for certain code) to Wall (enable warning and error diagnostics) option gets rid of most compiler warnings that are due to fmt. The same isn't true for icx/icpx (new Intel compilers), where both fmt 6.2.1 and 8.0.1 cause issues. (Edit: fwiw, I reported this as fmtlib/fmt#2619, which however is already closed)

@bryanwweber ... I think #1150 shed a few insights here. I dropped some of the commits that were not essential, and added 'experimental' support for icx: as long as optimization is disabled, things work. With that, I believe what is here is ready for review.

Just a thought -- you might not need to relax the tolerance on cxx-kinetics1 with the classic Intel compilers if the fp-model strict flag was added to that compiler set too. I don't know how important the tolerance and accuracy is for that case, but it might be worth checking (and deciding on importance).

@bryanwweber and @tpg2114 ... as the compilation issues are apparently not compiler related (see new issue #1155), I believe that Intel OneAPI can be added to the list of fully supported compilers at this point (as long as the required optimization settings are applied). I consolidated all commits and replaced the GH runner for icc by one for icx, where the previous 'fixes' for tolerances are no longer needed. As compilation with icx works (including pch support), this PR will close #1150, with the -ffast-math becoming a separate issue (which may or may not be worth pursuing).

I left the mingw runner in, but can drop it (or make a separate PR) in case the one failing test (where a band-aid is applied) needs further investigations.

I left the mingw runner in, but can drop it (or make a separate PR) in case the one failing test (where a band-aid is applied) needs further investigations.

I would suggest leaving the mingw compiler in, but I think the inconsistent return value arising from MixtureFugacityTP shouldn't be ignored by just making the test succeed if the result is either +2 or -2. The PengRobinson and RedlichKwong models both use this value and do not treat the positive and negative return values equally. I can create a new issue for this so it doesn't get lost.

For this PR, I would suggest skipping this test if the __MINGW32__ preprocessor define is present, e.g. something like:

#ifdef __MINGW32__
TEST_F(cubicSolver_Test, solve_cubic_DISABLED)
#else
TEST_F(cubicSolver_Test, solve_cubic)
#endif

@bryanwweber ... thanks for the review!

@speth ... thanks for the suggestion!

The PengRobinson and RedlichKwong models both use this value and do not treat the positive and negative return values equally. I can create a new issue for this so it doesn't get lost.

I excluded the test as suggested, but am not familiar enough to create an issue report. I tried tagging @gkogekar as this presumably is an edge case introduced by the PengRobinson PR #1047. FWIW, this is the output for the time being

[----------] 1 test from cubicSolver_Test
[ RUN      ] cubicSolver_Test.solve_cubic_DISABLED
[       OK ] cubicSolver_Test.solve_cubic_DISABLED (3 ms)
[----------] 1 test from cubicSolver_Test (3 ms total)

@bryanwweber ... you had a point when you mentioned that icc is likely going to be used for a while, so I tried @tpg2114's suggestion to disable fast math even for that compiler. This indeed took care of tolerances, and I added the OneAPI classic runner back in.