The script tools/toolchain/scripts/generate_arch_files.sh formed the wrong dependencies for replacement rules aka workarounds (.F instead of triggering .F90 aka FYPP). Disabled workarounds for certain compilation units when using Intel Compiler. Updated workaround rules even if commented out; avoid similar issues if WAs are ever needed for whatever compiler.

I'd like to remove the Makefile in a week or two, which will render generate_arch_files.sh obsolete. So, maybe we should convert the Intel tests to CMake before spending more time on them?

I'd like to remove the Makefile in a week or two, which will render generate_arch_files.sh obsolete. So, maybe we should convert the Intel tests to CMake before spending more time on them?

Yes, that's in mind and I will help with this whether it's here, with CMake, or with the Spack repo/recipes. Anyway, I will squeeze out the "value" (issues) of the failures here (Makefile) before moving on. I already reported the name clash for critical (this will be an extra comment).

Regarding name of CRITICAL sections, this is what our people say:

The names of critical constructs are global entities of the program. If a name conflicts with any other entity, the behavior of the program is unspecified.

Citation and reference is here.

As we all interpret the standard, there are different interpretations (let alone issues in the standard). Also, "there is hope for forgiveness and this shall become a warning rather than an error". It might be Intel follows GNU Fortran to accept a clashing name. That's my hope btw (aka IMHO).

I don't mind as long as it reliably throws an error - ideally with a meaningful message.
The part that worries me is: "the behavior of the program is unspecified".

It's not too bad to get an error and resolve via this PR (sure, I am affiliated ;-).

This now triggers other/unrelated issues, i.e., the ICE for hfx_contraction_methods.F, which will be reported too.