Re: Fortran testsuite?

[Craig Burley <burley at gnu dot ai dot mit dot edu>]

>> Well, the problem is some simulators don't give you an exit status
>> from the program.  Thus we have technology to "wrap" the exit
>> function to provide the information we need.
>
>I'm using "call exit(1)" until we come to some consensus on this.  It
>is true that it isn't portable - I remember using "call exit" which
>worked on at least one or two systems that didn't want an argument.
>Then it dumped core on the Sun, on which f77 wanted the argument.

Yup.  The problem with "CALL EXIT(n)" is that it isn't portable and
certainly not universal, but of course we can *make* it so for all
*g77* targets, thus dumping any actual problem on vendors wishing
to use our test suite, whose compilers do not support it.  :)

And, a problem with "STOP n" is that `n' must be a decimal
constant, and that, currently, and probably forever if I'm
guessing right about what Fortran users want, it is implemented
as "print a message, then stop with exit status 0 [success]".

So, even if we decided to change "STOP n" to mean "exit with status
code n", we'd have the problem of n having to be a constant to be
portable anyway -- and different systems have different values for
non-success.

BTW, here's a summary of g77/libf2c braking strategy, assuming
NO_ONEXIT isn't #define'd while building libf2c (and it shouldn't
be for most systems):

main(): Install f_exit() as the routine for exit() to call (via atexit()
  or whatever).  [gcc/f/runtime/libF77/main.c]
f_exit(): Close all open units via f_clos().  [gcc/f/runtime/libI77/close.c]
f_clos(): Close a unit, truncating/deleting file if necessary.  [ditto]
exit_(): Call exit() with status.  Invoked via CALL EXIT(n) by Fortran
  code, though g77's libf2c massages the name for reasons not pertinent
  to this summary, as the same effect is achieved.
  [gcc/f/runtime/libF77/exit.c]
s_stop(): If message not 0 characters long, print "STOP `msg' statement
  executed".  Then call exit(0).  Invoked via STOP.
  [gcc/f/runtime/libF77/s_stop.c]

(If NO_ONEXIT is #define'd, any code in libf2c that calls exit() first
calls f_exit().  So, the same effect is achieved, except any *other*
paths the program has to exit() won't call f_exit() -- e.g. if a library
or C code or something calls exit(), open units won't get closed,
which could mean things like partially overwritten files don't
get truncated.)

>FAIL: g77.tests/execute/alpha1.f execution,  -O0 
>
>I'm not sure if it should behave this way - Craig?

I'm not sure what that is -- I haven't downloaded any egcs stuff yet,
and probably won't get to it for another couple of weeks or so, due
to working on this new project pretty intensely.  (Which I should
really be doing now, as something *was* literally due yesterday.  :)

>Also, this little gem is in my archives from the g77 group:
>
>      CHARACTER*12 FUNC
>      WRITE(*,*) FUNC()
>      END
>C
>      CHARACTER*12 FUNCTION FUNC()
>      WRITE(2,'(A)') 'HELLO, WORLD'
>      FUNC = 'Goodbye, all'
>      RETURN
>      END
>
>gecko% g77 bad.f
>gecko% a.out
>I/O recursion: I/O started while already doing I/O
>apparent state: unit 6 (unnamed)
>last format: list io
>lately writing direct formatted external IO
>Abort (core dumped)
>
>The IBM xlf produces the same result.

Yup, that's exactly right.  Someday we'll (or dmg, libf2c maintainer,
will) probably teach libI77 to cope with recursive I/O on different
I/O units, but at least we give a nicer diagnostic in the 0.5.21
version of g77 than some obtuse crash, or worse.

        tq vm, (burley)