Closed hzhou closed 2 years ago
Follow up: Slightly modified the test program to also print "1st" element:
! explicitly initialize arrays
t1 = (/ 1, 2, 3, 4, 5 /);
t1_0 = (/ 0, 0, 0, 0, 0 /);
...
write(*,'(a6,2(1x,i2),f4.0)')'Low:',lbound(t1),lbound(t1_0), t1(1)
write(*,'(a6,2(1x,i2),f4.0)')'Upper:',ubound(t1),ubound(t1_0), t1_0(1)
Test with:
mpifort test.f90 && ./a.out
gcc-9.2
, it confirms the issue:
Array Configuration Before:
Low: 1 1 1.
Upper: 5 5 0.
Array Configuration After:
Low: 0 0 2.
Upper: 4 4 2.
icc
(ver. 19.0.3):
Array Configuration Before:
Low: 1 1 1.
Upper: 5 5 0.
Array Configuration After:
Low: 1 1 1.
Upper: 5 5 1.
I probably will look into it further and identify the exact issue, but it appears to be an issue with current gfortran
implementation.
Cross referencing in issue #3820, there reveals also a discrepancy related to the Fortran iso-c-binding between gfortran
and ifort
. In that case, our code works for gfortran
but fails ifort
(for legacy reason), even though I believe ifort
is more correct in its implementation.
Hello there, any updates on this? Can I help with something?
@pedro-ricardo We believe at this point this is an issue of gfortran
. Intel compilers (ifort
) seems ok.
Can it be isolated from MPICH and submitted as a issue to gcc?
Do you intend on making a workaround to enable mpi_f08
with gfortran while the bug isn't solved there?
Can it be isolated from MPICH and submitted as a issue to gcc?
The answer is probably yes. It will take some time (and unfortunately, some priority). Any help will be appreciated. If you would like to help, feel free to feed back to us on your effort. We'll be happy to discuss and provide pointers.
Do you intend on making a workaround to enable
mpi_f08
with gfortran while the bug isn't solved there?
The work-around is to skip iso-c-binding and do it in a similar way as the f90 modules. Of course, doing that defeats the original purpose of the f08 interface -- for its stronger type checking.
@pedro-ricardo: Have you submitted the bug to GCC yet?
Hello @gcorbin, No I did not.
Minimum reproducer:
t.f90
:
program t
INTERFACE
SUBROUTINE F_cdesc(buf) bind(C, name="F_cdesc")
IMPLICIT NONE
TYPE(*), DIMENSION(..), INTENT(in) :: buf
END SUBROUTINE
END INTERFACE
! Only reproducible with allocatable array. "INTEGER:: A(5)" would be fine.
INTEGER, allocatable, dimension(:):: A
allocate(A(5))
A = (/1, 2, 3, 4, 5/);
print*, A
write(*,'(a6,2(i2))') 'Before:', lbound(A), ubound(A)
! "CALL F_cdesc(A)" would be fine
CALL f08ts(A)
print*, A
write(*,'(a6,2(i2))') 'After:', lbound(A), ubound(A)
deallocate(A)
contains
SUBROUTINE f08ts(buf)
IMPLICIT NONE
TYPE(*), DIMENSION(..), INTENT(in) :: buf
call F_cdesc(buf)
END SUBROUTINE f08ts
end
cdesc.c
:
#include <ISO_Fortran_binding.h>
void F_cdesc(CFI_cdesc_t *buf) { }
Run with:
gcc-9 -c -o cdesc.o cdesc.c && gfortran-9 t.f90 cdesc.o -o t && ./t
Results:
1 2 3 4 5
Before 1 5
1 2 3 4 5
After: 0 4
EDIT: also reproduced with gcc 11
Reported to GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100
It will be fixed in the upcoming gcc-12.0 according to the reply in the above bugzilla report.
It is reported by a user on
discuss@mpich.org
:Hi there, My name is Pedro Ricardo and I'm currently a researcher at a Fluid Dynamics Laboratory in Brazil. We have a CFD software with 12 continuous years of development mostly in Fortran, and we've been using Mpich and Openmpi since the very beginning.
Recently we started to refactor the code and write it using Fortran2008 standard and this includes the usage of the the newest MPI module for Fortran "mpi_f08".
So far no errors were present in Openmpi implementations and everything worked like a charm, but when we started compiling with Mpich lots of errors happened during execution.
I was able so isolate and reproduce the error in a simpler code. Whenever "use mpi_f08" is present, the arrays passed to a MPI subroutine return with C-like indexes. If I allocate an standard array in Fortran (that starts with index 1), after the call of some MPI routine this array come back starting with index 0. And you can imagine that all access to this array will be wrong after that. It is a funny behavior because if you put "use mpi" instead of "use mpi_f08", the indexes do not change.
The test is simple, allocate and array, print it's bound indexes, calls a MPI_Reduce routine and print the array bounds again. I've also tested other routines like MPI_ISend and the error also happens.