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

[Dominique Dhumieres]

> 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 :)

Not exactly, (a) is fine with me.  In my opinion a well behaved compiler
should throw a warning for minor violations of the standard conformance
and an error otherwise, being aware that there are many cases where this
is very difficult or even impossible.

Now, repeating myself in a stronger way, hanging executables is in my opinion
the worst possible behavior (may be a tie with a wrong answer) that affect
a whole class of supported platform.  From this I can only see two outcomes:
(a) the support for Mac OSX is dropped, in which case I can guarantee that
I'll be as obnoxious as the guys who cried because their beloved emacs
did not bring them back to the error line when gfortran returned an error.
Everybody had to bend to their order within a week and they did not even
considered the alternative to modify the regexp to accomodate gfortran.
(b) find a way to remove the hanging, any solution from (a) to (d) + others
being OK.  I am perfectly aware about the fact that gcc is the work of
volunteers, having theis life outside gcc and their own agenda, thus I am not 
asking for a high priority to implement F2003 recursive IO.  I do not
intend to use recursive IO, legal or not, in my codes.  Basically I don't
understand their interest beside finding handy their use to debug other's 
codes, but I can live without it. 

In the meantime, I think this is not acceptable that a test case (as far as
I can tell there is only one: intrinsic_actual_2.f90) gives a hanging
executable.  Since I don't think the purpose of this testcase is to test
recursive IOs, it would probably be the best to modify it to avoid recursive
IOs (I think the test cases should be either standard conforming, or should
give errors or warning - note that I think that a nonconforming code giving
an ICE fall in the class of detectable nonconformity). A possible alternative
would be to declare the test case unsupported on Darwin: if I understand
the dejagnu stuff, it is a one line addition.

Now, all this said, I have reported the problem almost three months ago,
so I can wait again for a similar amount of time, knowing that would be the
nice guys who will do the work.  I am just upset by the lack of support 
at the level of the test suite. 

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

OK, my wording did not reflected what I had in mind:

(a) assuming the conformity of the recursive IO to the F2003 standard,
(b) assuming that I want to "optimize" the piece of code:

> tmp=fun(...)
> print *, tmp

to

> print *, fun(...)

give me a conforming example of fun(...) giving different outputs
for the two cases.  My example does not count for the present
implementation of gfortran under Linux: the result is the same
in both cases.  Now what I have in the back of my head, is that
if my bold and ignorant statement is true, this class of "false"
recursive IO could be implemented quite easily by using temporaries
ouside the IO instead of inside. Also if someone can give me an
example of a nontrivial application of recursive IO, I'll be interested.

Dominique