This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Fwd: (j3.2006) Fortran 2003 compiler features]
- From: dominiq at lps dot ens dot fr (Dominique Dhumieres)
- To: fortran at gcc dot gnu dot org
- Date: Mon, 5 Feb 2007 13:35:00 +0100 (CET)
- Subject: Re: [Fwd: (j3.2006) Fortran 2003 compiler features]
> > Recursive input/output
> > No.
>
> But it does sometimes work on some targets.
I have notified the problem on Mac OSX twice:
http://gcc.gnu.org/ml/fortran/2006-11/msg00394.html
on a gfortran test, and in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
for a reduced test case showing the problem on OSX 10.3 and 10.4 and
PPC and Intel architectures. So far the answer I have got are:
(a) Apple's fault,
(b) > > I believe recursive IO is undefined
> ...
> Undefined means undefined. It might do what you want on one
> platform and something entirely different on another.
The first time I replied:
> > In principle, gfortran can do anything.
>
> Hanging is probably the worse possibility.
and I did not care to repeat myself unril now. Note that xlf returns
a runtime error:
XL Fortran (I/O initialization): I/O recursion detected.
Abort
I clearly don't know the issues involved by recursive IOs, but for the
test I have given in pr30617 the recursivity is only due to how the code
is translated in the from end. If instead of
_gfortran_st_write (&dt_parm.1);
{
real4 D.951;
D.951 = fun ();
_gfortran_transfer_real (&dt_parm.1, &D.951, 4);
}
_gfortran_st_write_done (&dt_parm.1);
the front end has given
real4 D.951;
D.951 = fun ();
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_real (&dt_parm.1, &D.951, 4);
_gfortran_st_write_done (&dt_parm.1);
I am pretty sure that the problem would be gone (BTW is there a way to do
such move in an *.original file and to continue from it the compilation?).
>From my limited understanding of fortran above f90 and from what I have
read on different lists, if
tmp=fun(...)
print *, tmp
does not give the same result as
print *, fun(...)
the function fun(...) is almost certainly not standard conforming
(I someone has an example proving this is false, I'll be very glad to
study it!-).
Sorry for the frustration I may have expressed, but quite often I feel
Mac users ostracized by the gcc community ((a) is almost always
the first answer I get when I report a problem unless I take the time
to repreat the test on a linux box).
Dominique