[Fwd: (j3.2006) Fortran 2003 compiler features]

[François-Xavier Coudert]

> 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.

That's not true. Recursive I/O is defined by whether the Fortran
standard says it's recursive. In the case of PR30617, to my knowledge,
it *is* recursive I/O. Period.

Now, that doesn't mean we have to just ignore your report. But it
means that it will be lower priority, and we can either:
  (a) raise a runtime error,
  (b) print a runtime warning and do it nonetheless (it works on some systems),
  (c) document that it might work or not depending on the system,
  (d) find why it doesn't work, evaluate whether we can make it work
in the general case, make it work and document it as an extension

You're asking for (d), if I understand correctly. You'll have to admit
that it's probably the most difficult of all the options :)

> BTW is there a way to do
> such move in an *.original file and to continue from it the compilation?

No, the dump files only contain part of the tree information.
Otherwise, they would be unreadable.

> 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!-).

I think you've got an example for it: your PR testecase! :)

FX