berkley@wucs1.wustl.edu (Berkley Shands) (07/28/89)
In porting a LARGE fortran package to a MIPS based engine, (the decstation 3100 + the IRIS 4d power series) I ran across the following nasty bugs... 1) The compiler (with standard optimization) will optimize away identical argument lists to subroutine calls WHEN The calls follow each other using the EXACT SAME list, and the first argument is an array or a character string. call foo(a,b,c) call zor(a,b,c) The "a" argument is stack bound, but the data is trashed. It usually is a small fixed constant. The cure is to vary the argument list so it is not re-used by the compiler. 2) END=nn,ERR=NN on READS are really random branch statements. 3) The format (<var>L2) logical format, variable length, fixed size fields works on OUTPUT. On Input, that read and all subsequent reads will return NULLS or EOF. 4) The compiler is VERY picky about ENTRY statements. All entry points to a function/subroutine must share the SAME TYPE and ARGUMENT LISTS. 5) The runtime system (iris 4d this time) can lose file position on reads if to much I/O is done on consecutive i/o chanels (unit=1,unit=2...) 6) Passing character strings as arguments when the string is $INCLUDED and in common will sometimes pass trash or nulls. The larger the compilation unit, the worse the trouble. I hope this helps anyone trying to port VAX fortran to these noce FAST engines! Berkley Shands BERKLEY.WUSTL.EDU (BITNET) DECUS VAX SIG Exec
calvin@dinkum.wpd.sgi.com (Calvin H. Vu) (08/01/89)
In article <938@wucs1.wustl.edu>, berkley@wucs1.wustl.edu (Berkley Shands) writes: > > In porting a LARGE fortran package to a MIPS based engine, > (the decstation 3100 + the IRIS 4d power series) I ran across the following > nasty bugs... > > 1) The compiler (with standard optimization) will optimize away > identical argument lists to subroutine calls WHEN > The calls follow each other using the EXACT SAME list, and > the first argument is an array or a character string. > > call foo(a,b,c) > call zor(a,b,c) > > The "a" argument is stack bound, but the data is trashed. It usually > is a small fixed constant. The cure is to vary the argument list > so it is not re-used by the compiler. > I wrote a small test case based on your description: character*10 a call foo(a,b,c) call zor(a,b,c) end The assembler code generated for that test case does not show anything unusual. Anyway, there is no chance that any data can be trashed just by having two consecutive function calls with the same argument list. If you meant the wrong address for the first argument 'a' is passed to the function 'zor' then I think the problem is in having variable format inside the function 'zor'. There was a bug in the variable format extension that caused the first argument address to be zapped (normally with a small number, as you said). It has been fixed in the coming release of SGI's Fortran. This is purely guesswork though, since I could not reproduce your problem. > 2) END=nn,ERR=NN on READS are really random branch statements. > Do you mean 'nn' and 'NN' as valid Fortran labels or as variables containing random values ? Just kidding :-) :-). I have never heard of this problem from the thousands of customers using our Fortran and I don't think I can ever reproduce it. If you can create a test case and post it it would really help. > 3) The format (<var>L2) logical format, variable length, fixed size > fields works on OUTPUT. On Input, that read and all subsequent reads will > return NULLS or EOF. > This might be related to the variable format bug mentioned above. I made a test case and it worked fine though. > 4) The compiler is VERY picky about ENTRY statements. All entry > points to a function/subroutine must share the SAME TYPE and ARGUMENT LISTS. > There are two claims in this: 1) multiple ENTRY functions require same type: There was a bug that gave a compilation error if ENTRY functions return values of different types. This has been fixed on SGI systems (Sorry, that's all I know). 2) same argument list : Can you elaborate on this ? > 5) The runtime system (iris 4d this time) can lose file position > on reads if to much I/O is done on consecutive i/o chanels (unit=1,unit=2...) > I can't see any difference having logical unit number 1 instead of 1000001. After all, all logical unit numbers are just that: symbolic numbers that map to some internal file pointers. I just can't see any connection between unit 1 and 2 nor unit 1 and 1000001 nor any two numbers for that matter. If I'm going to lose anything, I think I'm going to lose my mind before I lose file position on logical unit 1 because I just write to logical unit 2 instead of 1000002. > 6) Passing character strings as arguments when the string is > $INCLUDED and in common will sometimes pass trash or nulls. The larger > the compilation unit, the worse the trouble. > Again, something more concrete is needed to identify the bug. Anyway, this is my guess of the problems you are having: 1) first argument gets zapped by having variable format extension in the subroutine 2) multiple-entry functions return values of different types. 3) using character-type arguments in multiple-entry subroutines. All of them have been fixed in SGI's 3.2 release. If you call up SGI Hot Line they may be able to help you. > I hope this helps anyone trying to port VAX fortran It will be much more helpful if you can pinpoint where the problem is with a concrete test case or a more detailed description so other users can circumvent it and MIPS/SGI/DEC can fix it for future releases. > these noce FAST engines! > I agree. I even heard rumors that they are twice as fast as the Cray in certain compute-extensive benchmark. :-; > Berkley Shands > BERKLEY.WUSTL.EDU (BITNET) > DECUS VAX SIG Exec Hope it helps. If you can come up with a valid example of any bugs on an SGI system, please call up the Hot Line or e-mail it to me, I will try to help whenever I have a break :-(. ------------------------------------------------------------------------- Calvin Vu | Where's my pen ? Where's my signature ? Silicon Graphics | What do you mean ? Are you saying that calvin@sgi.sgi.com | I'm losing my identity right in the middle | of this mountain of stuff ? Hey, boss, | what is my title ?