Use -standard-semanics by default with Intel compilers

[awvwgk]

Using this option would ensure that a more standard compliant mode is used with Intel compilers. Alternatively, this could be specified as an option in the Fortran table:

[fortran]
standard = "compiler-default"  # or "f2023", "f2018", ...

See also https://fortran-lang.discourse.group/t/5451/22

[urbanjost]

See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/standard-semantics-switch-causes-the-g0-descriptor-to-generate/m-p/1476800/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExHR1I3TUdQS09JRVkzfDE0NzY4MDB8U1VCU0NSSVBUSU9OU3xoSw#M166082

[perazz]

Relevant for #901. We need to turn standard-semantics on with ifort, because lhs reallocation is not enabled by default otherwise. That means that most of the code ought to be rewritten (allocatable character variaboles).

[ivan-pi]

While written in the context of logical values and C interoperability, the Intel documentation states that:

If you are going to use LOGICAL types to interoperate with C, specify the option fpscomp[:]logicals to change the interpretation to be C-like. This is included when using the option standard-semantics, which is recommended for using Fortran 2003 (or later) features. [emphasis added]

[ivan-pi]

Relevant for #901. We need to turn standard-semantics on with ifort, because lhs reallocation is not enabled by default otherwise. That means that most of the code ought to be rewritten (allocatable character variaboles).

To solve that issue you would need just the -assume realloc_lhs flag. It appears like there is no -nostandard-semantics flag. One needs to "opt in" to all of the non-standard behaviors using -assume..

[perazz]

This has been introduced in #901, should we close this issue @awvwgk?

[awvwgk]

This is resolved now

[zoziha]

@awvwgk @perazz

After my performance testing of several test codes, ifort/ifx with the /standard-semantics compiler option enabled, the compiled programs generally resulted in a performance degradation of about 15%~146% on Windows.
I think we should reconsider the scope of the /standard-semantics compiler option, and I suggest removing the use of the /standard-semantics compiler option from the fpm release profile.

For example, if you run code fortran-lang/benchmarks: poisson2d/optimized.f90 with M set to 128, ifort/ifx will run as:

> ifort /O3 /fp:precise /align:all /error-limit:1 /reentrancy:threaded /nogen-interfaces /assume:byterecl main.f90; ./main
   7.23437500000000            84198
> ifort /O3 /fp:precise /align:all /error-limit:1 /reentrancy:threaded /nogen-interfaces /assume:byterecl /standard-semantics main.f90; ./main
 13.1562500000000 84198
> ifx /O3 /fp:precise /align:all /error-limit:1 /reentrancy:threaded /nogen-interfaces /assume:byterecl main.f90; ./main
   10.3437500000000            84198
> ifx /O3 /fp:precise /align:all /error-limit:1 /reentrancy:threaded /nogen-interfaces /assume:byterecl /standard-semantics main.f90; ./main
 16.7968750000000 84198

The performance of ifort/ifx with /standard-semantics drops by 82%/62% respectively. It can also be seen that the default table control format with /standard-semantics enabled is different.

[perazz]

@zoziha without /standard-semantics, fpm does not build, see #898 #901