ICL ifort version synchronization update

[TimP]

I've installed the recently distributed ifort update 2021.1 Build 20201112 with VS2017 but ICL remains at 19.0 Build 20181018 so the objects refuse to link together.  For background, I hadn't updated VS2017 since changing successfully at last from Windows 8.1 (which no longer booted reliably) to 10.  I had error indications in the oneAPI install until I completed the VS2017 upgrade, then ifort installed with no trouble.  I can build successfully with the CL and ifort combination.  I've tried Modify to remove and reinstall C++, and removed oneAPI entirely and re-installed, and still the older ICL comes up.

[TimP]

OK, the main problem is having to switch to compiler ICX in the Makefile.  I'm surprised that ICL is defined to be the old compiler from another installation.  It's also complaining about many Intel specific options and directives, and reporting disabled optimizations (which may not have done anything useful).  It no longer needs -Qstd=c99 for restrict qualifier used for Fortran compatibility, and the linker now catches missing "extern" for linking to Fortran defined data regions.

It's been tough to get back to this forum, although the old problem of intermittent visibility on internet seems to have been fixed (no blocking by AT&T on my current service).

[mecej4]

Tim, unless you chose not to install the ICL component, you should have both ICX and ICL available in OneAPI.

S:\sort>icl
Intel(R) C++ Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1 Build 20201112_000000

S:\sort>icx
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2021.1 Build 20201113

S:\sort>ifort
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1 Build 20201112_000000

S:\sort>ifx
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2021.1 Beta Build 20201113

I have not seen any OBJ incompatibility except when I tried use IFX to produce objects for  IA32 targets. This kind of usage is probably not supported, anyway, since code generation and support for IA32 is being phased out.