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)
On Mon, 20 Aug 2007 06:29:51 -0700, mreste...@gmail.com wrote (in article <1187616591.093651.68...@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
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)
*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 ?
> *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 ?
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.
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...
-- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
> 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.
Dnia 20-08-2007, pon o godzinie 15:01 -0400, Craig Powers napisał(a):
> 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.
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 ;)
|
