This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]