[comp.lang.fortran] Green Hills Fortran I/O init on Xenix

segall@caip.rutgers.edu (Ed Segall) (10/21/90)

HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I'm working on an Intel iPSC/2, running Green Hills FORTRAN under
Xenix.  I've managed to successfully link C and Fortran routines (with
the main procedure being in C), except for one nasty little detail:

The fortran I/O doesn't work!

Here's the details:


I am calling fortran subroutines from a c main program, and the
fortran i/o is causing runtime errors. It doesn't cause any problems
when the main program is fortran.  I don't believe it's a problem with
argument passing, since I can reproduce the error without passing any
values.  In fact, a C program that does nothing but call a fortran
subroutine (with no parameters), which does nothing but print, causes
the problem.  Also, I've had no trouble passing values from fortran to
C and then having C print them.  (If necessary, I'll rewrite
everything so that C does the output, but I'd rather fix the problem
properly). 

Some versions of fortran have a special function that you can 
call that initializes the i/o system.  On the Sun, it's called ioinit.
Do you know if such a thing exists for the iPSC, and if it does,
what it's called and what parameters it takes? I'd appreciate it 
very much if you would check.

Here's the code:

c program (testc.c)
-----------------------------------------------------------------------------
#include <stdio.h>
extern void     testf_();

main()
{
        printf("c: ready to call testf()\n");
        testf_();
        printf("c: passed call to testf()\n");
}
-----------------------------------------------------------------------------

fortran (testf.f)
-----------------------------------------------------------------------------
        subroutine testf()
        integer i

        print *, 'f: in testf'
        i = 1
        print *, 'f: i = ', i
        end
-----------------------------------------------------------------------------

How compiled & linked:
-----------------------------------------------------------------------------
f77 -c -g testf.f
cc -g testc.c -o test testf.o -lf -lm
-----------------------------------------------------------------------------

output:
-----------------------------------------------------------------------------
c: ready to call testf()
test: Segmentation violation -- Core dumped
-----------------------------------------------------------------------------

Note that no output appears from fortran.  Sometimes (I'm not sure of
the circumstances, but I think it may be if I flush stdout), some of
the fortran output appears in a file called Fort.6.  This suggests to
me that something isn't getting initialized, so a default file name is
being used.  Also, if I open unit 6 as /dev/tty, and then do
	write(6,*) 

instead of 
	print *,...  

this allows some fortran output to appear on stdout, but only if I
just print strings.  I.e. the first print statement (if converted to
write) appears, but the second causes the program to break.

This is causing me real problems, and has made it unlikely that I'll
be able to present my results (with regard to the particular program
I'm working) at a conference at the end of this week.  If there's
anything you can do to find out how to fix or work around this, I'd
appreciate it.

Thank you,

Ed

PS This happens both on nodes (where it causes a segmentation
violation) and on the host (where it causes a bus error).


PPS  Here's another version of the same program, that explicitly opens
unit 6, and does formatted output (to remove any ambiguity about what
the i/o system has to do):

fortran (testwritef.f):
-----------------------------------------------------------------------------      subroutine testf()
      integer i

      i = 1
      open(unit=6, file='/dev/tty')
      write(6,100)
  100 format('f: in testf')
      write(6,101) i
  101 format('f: i = ', i4)
      end
-----------------------------------------------------------------------------

c (testwritec.c, same as testc.c):
-----------------------------------------------------------------------------
#include <stdio.h>
extern void     testf_();

main()
{
        printf("c: ready to call testf()\n");
        testf_();
        printf("c: passed call to testf()\n");
}
-----------------------------------------------------------------------------


output:
-----------------------------------------------------------------------------
c: ready to call testf()
f: in testf
testwrite: Bus error -- Core dumped
-----------------------------------------------------------------------------

Note that with unit 6 opened explicitly, the fortran output does appear.

How made:
-----------------------------------------------------------------------------
f77 -c -g testwritef.f
cc -g testwritec.c -o testwrite testwritef.o -lf -lm
-----------------------------------------------------------------------------
-- 


uucp:   {...}!rutgers!caip.rutgers.edu!segall
arpa:   segall@caip.rutgers.edu

rfg@NCD.COM (Ron Guilmette) (10/22/90)

In article <Oct.20.17.49.23.1990.10138@caip.rutgers.edu> segall@caip.rutgers.edu (Ed Segall) writes:
>
>HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>I'm working on an Intel iPSC/2, running Green Hills FORTRAN under
>Xenix.  I've managed to successfully link C and Fortran routines (with
>the main procedure being in C), except for one nasty little detail:
>
>The fortran I/O doesn't work!

I don't know why anybody would want to use third part fortran compilers
anymore, at least now that there is a public domain f2c (fortran to C)
translator and the GNU C compiler.

I believe I have seen statements on the net to the effect that f2c+gcc
actually beats many vendor's FORTRAN compilers in terms of performance.

The only reason I can think of for people's continued use of other FORTRAN
compilers is that the necessary debugger support for f2c might not be fully
there yet, but IMHO, that's a solvable problem.
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

bgg@pta.oz.au (Ben Golding) (10/23/90)

In article <2175@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <Oct.20.17.49.23.1990.10138@caip.rutgers.edu> segall@caip.rutgers.edu (Ed Segall) writes:
>>I'm working on an Intel iPSC/2, running Green Hills FORTRAN under
>>Xenix.  I've managed to successfully link C and Fortran routines (with
>>the main procedure being in C), except for one nasty little detail:
>>
>>The fortran I/O doesn't work!
>
>I don't know why anybody would want to use third part fortran compilers
>anymore, at least now that there is a public domain f2c (fortran to C)
>translator and the GNU C compiler.

One simple reason: support.  Not everyone is prepared to use a product
where they have to fix its bugs themselves.

Ed's problem may be because the main() that is normally linked from
Fortran's library initialises the I/O library before it calls the
user's Fortran routine.  Providing your own main() means that this
initialisation isn't done.  In the Pyramid compiler and many other unix
Fortran implementations, the routine to do this is called f_init().
Try calling that before you call the Fortran subroutine.  The
corresponding routine to wind down the I/O library is f_exit().

If you get f_init and f_exit undefined, look through the namelist of
the I/O library (traditionally /usr/lib/libI77) for another candidate.

	Ben Golding <bgg@pta.oz.au>

md (Michael Davidson) (10/25/90)

segall@caip.rutgers.edu (Ed Segall) writes:

>I'm working on an Intel iPSC/2, running Green Hills FORTRAN under
>Xenix.  I've managed to successfully link C and Fortran routines (with
>the main procedure being in C), except for one nasty little detail:

>The fortran I/O doesn't work!

>Here's the details:

[ assorted woes about fortran i/o apparently not being initialised ... ]

I'm not familiar with Green Hills Fortran, but I suspect that you may
be able to kludge your way round this - sounds like you have a C program
that is trying to call some Fortran routines - why not use a small
Fortan MAIN program (so that Fortran gets initialised correctly) - call
your real C main() (suitably renamed, and with suitable adjustments
to the argc parameter which you will have to pass in by reference
rather than by value) from Fortran, and then everything should work
just fine. ...