LEN of subroutine variables

[mres...@gmail.com]

Hello,
I would like to ask you if the following code is legal (notice the
LEN type parameter of MOD_B_STRING):

module mod_a
implicit none
character(len=100) :: mod_a_string
end module mod_a

module mod_b
use mod_a
implicit none

contains

subroutine mod_b_sub()
character(len=len(trim(mod_a_string))+2) :: &
mod_b_string

mod_b_string = trim(mod_a_string) // '!!'
write(*,*) mod_b_string

end subroutine mod_b_sub
end module mod_b

program test_string

use mod_a
use mod_b

implicit none

mod_a_string = 'Hello'
call mod_b_sub()

end program test_string

When this code is compiled with gfortran or ifort, it behaves "as
expected", in that it prints Hello!! (no warning even when using all
the debugging options). Also, valgrind shows no errors. With pgf,
however, the code compiles with no errors but at runtime produces a
huge blank output. Here, valgrind complains about "Conditional jump or
move depends on uninitialised value(s)" at CALL MOD_B_SUB().

(more details:
gfortran --version
GNU Fortran 95 (GCC) 4.1.2 (Gentoo 4.1.2)
ifort --version
ifort (IFORT) 9.1 20061101
pgf95 -V
pgf95 6.1-1 32-bit target on x86 Linux)

Thank you!
Marco Restelli

[Richard Maine]

On Mon, 20 Aug 2007 06:29:51 -0700, mres...@gmail.com wrote
(in article <1187616591....@k79g2000hse.googlegroups.com>):

> I would like to ask you if the following code is legal (notice the
> LEN type parameter of MOD_B_STRING):

[code elided]

Yes, that looks fine. It is even ok in f90. (This is an area where things got
progressively more liberal with each version of the standard, but this one
looks ok for f90 and later).

> When this code is compiled with gfortran or ifort, it behaves "as
> expected", in that it prints Hello!! (no warning even when using all
> the debugging options). Also, valgrind shows no errors.

Good.

> With pgf, however,...

I'd suggest a bug report. Pgf isn't the most robust compiler out there. It is
better than it used to be, but still has plenty of room to go.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

________________________________________________

Hogwasher, Premier News and Mail for OS X
http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html
________________________________________________

[Paul Hilscher]

Hello,

I'm trying to port a data saving routine from a FORTRAN 77 program to
Fortran 95 but stuck with the following read problem :

FORTRAN 77 'unform_types.f':

program main
implicit none
integer :: i = 7, j, k
open(unit=12,file='Itype77.dat',status='replace',
% form='unformatted')
write(12),i
close(12)

open(unit=12,file='Itype95.dat',form='unformatted')
read(12),j
close(12)
write(*,*) 'Itype95', j

open(unit=12,file='Itype77.dat',form='unformatted')
read(12),k
close(12)
write(*,*) 'Itype77', k

end program main

the "ported" Fortran 95 Code 'unform_types.f95' :

program main
implicit none
integer(kind=4) :: i = 7, j, k
open(unit=12,file='Itype95.dat',status='replace', &
form='unformatted')
write(12),i
close(12)

open(unit=12,file='Itype95.dat',form='unformatted')
read(12),j
close(12)
write(*,*) 'IType95', j

open(unit=12,file='Itype77.dat',form='unformatted')
read(12),k
close(12)
write(*,*) 'IType77', k

end program main

*Compiling with:
philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$ ls -l Itype*
-rw-r--r-- 1 philscher philscher 12 2007-08-20 19:17 Itype77.dat
-rw-r--r-- 1 philscher philscher 20 2007-08-20 19:17 Itype95.dat
philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$

f95 -o for95 unform_types.f95 &
f77 -o for77 unform_types.f

*and running, produces following results on my machine

philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$ ./for77
Itype95 0
Itype77 7
philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$

*and

philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$ ./for95
IType95 7
IType77 4
philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$

philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$ ls -l Itype*
-rw-r--r-- 1 philscher philscher 12 2007-08-20 19:17 Itype77.dat
-rw-r--r-- 1 philscher philscher 20 2007-08-20 19:17 Itype95.dat
philscher@Ariel:~/Science/HiWi - MPIA/Hydrocode/FortranBox$

*Why are the results different ? The programs produces Itype*.dat files
that are different in size. I played around with the integer(kind=...)
parameter in the F-95 Code but never get the desired result. I think the
problem lies that Fortran-95 uses a 8-byte long record header, while
F-77 uses only 4-byte. But why is this so and what should I do to get
things work ?

Thanks for reading & helping

Paul

[Gordon Sande]

Probably. Why does it matter? Unformatted i/o is intended to be read in
by the same program (or at least one of its close relatives). Reading
by diferent programs that have different record conventions, as you
describe, is always a bother. There may be "compiler" options that
inform the run time system of your preferences. RTFM very carefully.
Some vendors have utilities that will convert the record headers or
you can do it yourself if this is going to be an ongoing bother.

[Richard Maine]

On Mon, 20 Aug 2007 10:26:18 -0700, Paul Hilscher wrote
(in article <1187630777.20834.17.camel@Ariel>):

> I think the
> problem lies that Fortran-95 uses a 8-byte long record header, while
> F-77 uses only 4-byte. But why is this so and what should I do to get
> things work ?

This is a function of the particular compilers involved - not of f77 versus
f95 in general. Unless I missed it, you didn't mention the particular
compilers you used. As Gordon mentioned, unformatted I/O is not generally
guaranteed to be interoperable between different compilers. This is *NOT*
related to f77 versus f90. There were f77 compilers with many, many different
variants of unformatted file formats... not to speak of the detail that there
were historically lots of different binary data representations. Things have
converged quite a bit today; there are still multiple variants, but not
nearly as many as there used to be.

I wonder if you are using gFortran for your f95 compiler. Most f95 compilers
go out of their way to use a scheme that is compatible with the most common
existing practices. I seem to recall that gFortran had (has?) an option
related to this, but that the default was to be incompatible. I thought that
a poor choice, but...

[Craig Powers]

Richard Maine wrote:
>
> I wonder if you are using gFortran for your f95 compiler. Most f95 compilers
> go out of their way to use a scheme that is compatible with the most common
> existing practices. I seem to recall that gFortran had (has?) an option
> related to this, but that the default was to be incompatible. I thought that
> a poor choice, but...

If I'm not mistaken, gfortran has somewhat recently switched to using
the ifort scheme for extended record sizes, with compatibility options
for the original extended record size usage.

[Paul Hilscher]

Indeed, with gfortran -frecord-marker=4 everything works fine, thanks a
lot for the hint !
According to the gfortran manual they changed this to be
the new default value for version 4.2.1+, so bad luck for me ubuntu came
with version 4.1 ;)

Paul