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