Newsgroups: comp.sys.isis Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!ken From: ken@CS.Cornell.EDU (Ken Birman) Subject: Re: isis fortran interface on DECstation Message-ID: <1991Jun13.193813.16511@cs.cornell.edu> Sender: news@cs.cornell.edu (USENET news user) Nntp-Posting-Host: fafnir.cs.cornell.edu Organization: Cornell Univ. CS Dept, Ithaca NY 14853 References: <1991Jun12.184807.25396@cs.cornell.edu> Distribution: comp Date: Thu, 13 Jun 1991 19:38:13 GMT Lines: 51 In article souva@babsy.mpifr-bonn.mpg.de writes: >Has anybody ported the F77 interface to the DECstation? I tested further and the main problem may be in the DEC optimizer and not in the fortran port itself. When I compiled with -O, things blow up, but when I recompiled flib1.c and flib2.c without -O, it was fine. I was able to isolate the following simple test program that illustrates the compiler bug. If you look at the assembler code produced, you will see that the compiler decided to eliminate the code to save the result from the call to "def" and leaves it in a register, but then uses that register as a temporary storage place when computing the somewhat messy expression right after the call to def() in procedure abc(). Unfortunately, this is the expression generated by the ENDFROMFORTRAN macro... I don't know if this affects anything else in ISIS. I hope not! /* Convince a skeptic that DEC code optimizer has a bug */ #include int save, i; int j; main() { j = abc(1234); printf("After call: should be 9876, got %d\n", j); } abc(x) { char *rval, *def(); save = i; i |= 0x100; rval = def(x); i = (i&~0x100) | (save&0x100); return (int)rval; } char * def(x) { return((char*)9876); } -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428