FWIW, I can replicate the behavior with gfortran 4.7.2: - program runs "fine" with no MPI_Init/MPI_Finalize - program dumps core when MPI_Init/MPI_Finalize are called (at the "conc = [ xx, yy ]" statement)
I notice that even if I disable Open MPI's memory hooking, the coredump still occurs. Sidenote: there's a few ways to disable OMPI's memory hooking; one of the easiest is to set the environment variable FAKEROOTKEY to any value, because OMPI disables its memory hooking in Debian Fakeroot environments. For example: ----- % setenv FAKEROOTKEY 0 % mpifort -g arrays.f90 && ./a.out *** glibc detected *** ./a.out: free(): invalid pointer: 0x000000369ef9cf48 *** ...etc. ----- Specifically: with OMPI's memory hooking disabled, we don't modify the behavior of malloc/free/memalign/realloc. I'm not sure what Open MPI is doing to anger the gfortran gods, but I did note that when I run the program without MPI_Init/MPI_Finalize, valgrind complains: ----- ==7269== Conditional jump or move depends on uninitialised value(s) ==7269== at 0x4015B0: MAIN__ (arrays.f90:20) ==7269== by 0x401795: main (arrays.f90:26) ----- Line 20 is the "conc = [ xx, yy ]" statement. I'm not enough of a Fortran guru to know what that means (to my eyes, xx and yy were just initialized above that -- perhaps it's complaining about conc?), but there you go. :-) On Jan 14, 2013, at 6:08 AM, Stefan Mauerberger <stefan.mauerber...@gmail.com> wrote: > Well, I missed to emphasize one thing: It is my intension to exploit > F2003's lhs-(re)allocate feature. Meaning, it is totally legal in F03 to > write something like that: > integer, allocatable :: array(:) > array = [ 1,2,3,4 ] > array = [ 1 ] > where 'array' gets automatically (re)allocated. One more thing I should > mention: In case 'array' is manually allocate, everything is fine. > > Ok, lets do a little case study and make my suggested minimal example a > little more exhaustive: > PROGRAM main > > IMPLICIT NONE > !INCLUDE 'mpif.h' > > INTEGER :: ierr > > TYPE :: test_typ > REAL, ALLOCATABLE :: a(:) > END TYPE > > TYPE(test_typ) :: xx, yy > TYPE(test_typ), ALLOCATABLE :: conc(:) > > !CALL mpi_init( ierr ) > > xx = test_typ( a=[1.0] ) > yy = test_typ( a=[2.0,1.0] ) > > conc = [ xx, yy ] > > WRITE(*,*) SIZE(conc) > > !CALL mpi_finalize( ierr ) > > END PROGRAM main > Note: For the beginning all MPI-stuff is commented out; xx and yy are > initialized and their member-variable 'a' is allocated. > > For now, assume it as purely serial. That piece of code complies and > runs properly with: > * gfortran 4.7.1, 4.7.2 and 4.8.0 (experimental) > * ifort 12.1 and 13.0 (-assume realloc_lhs) > * nagfort 5.3 > On the contrary it terminates, throwing a segfault, with > * pgfortran 12.9 > Well, for the following lets simply drop PGI. In addition, according to > 'The Fortran 2003 Handbook' published by Springer in 2009, the > usage of the array constructor [...] is appropriate and valid. > > As a second step lets try to compile and run it invoking OMPI, just > considering INCLUDE 'mpif.h': > * gfortran: all right > * ifort: all right > * nagfor: all right > > Finally, lets initialize MPI by calling MPI_Init() and MPI_Finalize(): > * gfortran + OMPI: *** glibc detected *** ./a.out: free(): invalid > pointer ... > * gfortran + Intel-MPI: *** glibc detected *** ./a.out: free(): invalid > pointer ... > * ifort + OMPI: all right > * nagfor + OMPI: all right (-thread_safe) > > Well, you are right, this is a very strong indication to blame gfortran > for that! However, it gets even more confusing. Instead of linking > against OMPI, the following results are obtained by invoking IBM's MPI > implementation: > * gfortran + IBM-MPI: all right > * ifort + IBM-MPI: all right > Isn't that weired? > > Any suggestions? Might it be useful to submit a bug-report to GCC > developers? > > Cheers, > Stefan > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
