gfortran's -fallow-argument-mismatch with old/new compilers

[Thomas Koenig]

I recently had an e-mail from somebody who ran into trouble
with old code on gfortran - gfortran 9 did not have the
-fallow-argument-mismatch flag, but gfortran 11 required it due
to issues in the code.

The solution I proposed was to add something like

FC_OPTIONS="-O2"
cat > optiontest.f90 <<EOF
end
EOF
gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
2>/dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
echo $FC_OPTIONS
rm optiontest.f90

to his build scripts, which will add the flag to the FC_OPTIONS
variable if it is supported, and I thought I'd share it.

[mies...@gmail.com]

It is certainly an MPICH issue, but I am still using gfortran version 9.2.1 just to avoid this -fallow-argument-mismatch flag when compiling MPICH for use with gfortran and OpenCoarrays. To me, it appears that this flag is somehow related to severe performance issues with MPICH and coarray programming. (Same issue with ifort: Intel MPI is MPICH but I can’t tell if they use a similar flag with Intel MPI).

I did already describe my problem here:
https://fortran-lang.discourse.group/t/coarrays-not-ready-for-prime-time/2715/61
https://fortran-lang.discourse.group/t/coarrays-not-ready-for-prime-time/2715/65

Let me add that the overall performance of a coarray program my not necessarily appear to change much when using this flag with compiling MPICH. The performance issue is slightly more subtle with my current test cases:

- compiling MPICH without the flag (using gfortran 9.2):
Allocating few (allocatable) coarray components takes multiple seconds (8-9 seconds on my laptop) which is of course way too slow. But then, once the coarrays are all allocated, execution of the specific parts (subtasks) with my test cases takes less than 0.04 second for each part. (I am using a time-out function that requires this time limit as a minimum).

- compiling MPICH with the flag (using newer versions of gfortran or just use a recent ifort compiler version which shows the exactly same poor performance on my laptop):
Allocating few (allocatable) coarray components is now very fast (less then 0.2 seconds on my laptop). But now execution of the specific parts (subtasks) with my test cases takes only less than 2(!) seconds for each part (time-out function requires this time limit as a minimum), which is way too slow for anything serious. Output on screen shows this very poor performance as well.

Note: the shift from 0.04 second to 2 full seconds!

Thus, my preferred setup is still using gfortran 9.2 / OpenCoarrays 2.8.0 / MPICH (3.2.1/3.4.3/4.0.1) on my laptop to already (and massively) prepare programming with Fortran for the upcoming era of (heterogeneous) spatial accelerators. To me, the quality of even this old (2019) gfortran/OC CAF implementation is still ahead of Intel’s ifort (which latest version I am using so far is 2021.5).

Regards

[Thomas Koenig]

mies...@gmail.com <mies...@gmail.com> schrieb:

> Thomas Koenig schrieb am Sonntag, 12. Juni 2022 um 13:53:27 UTC+2:
>> I recently had an e-mail from somebody who ran into trouble
>> with old code on gfortran - gfortran 9 did not have the
>> -fallow-argument-mismatch flag, but gfortran 11 required it due
>> to issues in the code.
>>
>> The solution I proposed was to add something like
>>
>> FC_OPTIONS="-O2"
>> cat > optiontest.f90 <<EOF
>> end
>> EOF
>> gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
>> 2>/dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
>> echo $FC_OPTIONS
>> rm optiontest.f90
>>
>> to his build scripts, which will add the flag to the FC_OPTIONS
>> variable if it is supported, and I thought I'd share it.
>
> It is certainly an MPICH issue, but I am still using gfortran
> version 9.2.1 just to avoid this -fallow-argument-mismatch flag
> when compiling MPICH for use with gfortran and OpenCoarrays. To me,
> it appears that this flag is somehow related to severe performance
> issues with MPICH and coarray programming.

I can assure you it is not - the change in question is purely something
that will downgrade a newly introduced error to a warning.

Any Performance issues you are seeing may be related to the
interplay of the OpenCoarrays library with MPICH. Since
I know neither well, I cannot really comment on that.

[gah4]

On Friday, June 17, 2022 at 8:01:36 AM UTC-7, Thomas Koenig wrote:
(snip)

> I can assure you it is not - the change in question is purely something
> that will downgrade a newly introduced error to a warning.

> Any Performance issues you are seeing may be related to the
> interplay of the OpenCoarrays library with MPICH. Since
> I know neither well, I cannot really comment on that.

Which leaves out the question about the check itself, and whether it is
only a compile-time test, or a run-time test.

In any case, it could be some unrelated change in the compiler
that happens with that version, that is causing the timing change.

But also note, one must be very careful with any timing tests.
For example, data in the file cache can make a program run much
faster, not having to read it off disk. If you run program A then B,
it might be that B runs much faster, with cached data. But run A
again and see if the time changes.

But timing gets even harder with multiple threads, as it depends
on any interaction of the threads, along with everything else
(such as the disk cache).

[mies...@gmail.com]

My personal guess is that this performance issue is not due to gfortran, not due to OpenCoarrays, and not due to ifort, but only due to MPICH. Recent releases of gfortran/OpenCoarrays and ifort show the exactly same (poor) run-time performance pattern. And Intel MPI is MPICH. Earlier releases of ifort did perform as fast as my setup with gfortran 9.2 and OpenCoarrays.
And, for reasons that I can’t understand, the poor performance pattern with gfortran/OpenCoarrays occurs whenever the compilation of MPICH leads to:

mpich 4.0.1 ./configure
checking whether gfortran allows mismatched arguments... yes, with -fallow-argument-mismatch
configure: error: The Fortran compiler gfortran does not accept programs that call the same routine with arguments of different types without the option -fallow-argument-mismatch. Rerun configure with FFLAGS=-fallow-argument-mismatch and FCFLAGS=-fallow-argument-mismatch

[mies...@gmail.com]

Just to make this more complete:
From what I did see, the poor performance pattern is not necessarily a poor performance of the image-to-image data transfers with synchronization (through MPICH), but may rather be a poor performance of executing the purely local codes (and in my case with oversubscribing cores, i.e. using more coarray images than hardware cores are available).

[Wyatt Spear]

I was examining the docs (https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html) and it turns out that -fallow-argument-mismatch is implied by -std=legacy. -std=legacy is allowed by at least some versions that will reject -fallow-argument-mismatch. Switching to -std=legacy worked for my use case, removing the need for a compatibility test. Just be careful in case -std=legacy has other, less desirable, effects.

[Thomas Koenig]

Wyatt Spear <wjs...@gmail.com> schrieb:

> I was examining the docs
>(https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html)
> and it turns out that -fallow-argument-mismatch is implied by
> -std=legacy.

That is correct.

>-std=legacy is allowed by at least some versions that
> will reject -fallow-argument-mismatch.

That was the idea, for backwards compatibility.

> Switching to -std=legacy
> worked for my use case, removing the need for a compatibility
> test.

That can be done.

I would still recommend using the test because

>Just be careful in case -std=legacy has other, less desirable,
>effects.

you are right there: -std=legacy accepts a lot of code that is
not in the user's best interest to have :-)

[Patrick Pereira]

For me worked with ./configure --prefix=/exports/mpich2 FCFLAGS=-std=legacy FFLAGS=-fallow-argument-mismatch