mjs@hubcap.clemson.edu (m j saltzman) (10/22/90)
I discovered an error in a FORTRAN program I was modifying, which amounts to the following: SUBROUTINE FOO(X, [other parameters], X) DOUBLE PRECISION X(N) [rest of code] This compiled without error on a Sun (with the -u flag) and on ULTRICS. Fortunately (?), the calling routine supplied the same argument in both positions, so no error occurred during execution. Questions: Is this really legal FORTRAN 77? If so, is it useful for anything? What are the semantics of a call to the routine with different arguments, say FOO(Y, ..., Z)? If not, why don't common compilers (at least these) detect the error? Other types of duplicate declarations are detected. Thanks for any insight. Matthew Saltzman mjs@clemson.edu
burkley@cod.NOSC.MIL (V. J. Burkley) (10/23/90)
In article <11084@hubcap.clemson.edu> mjs@hubcap.clemson.edu (m j saltzman) writes: >I discovered an error in a FORTRAN program I was modifying, which amounts >to the following: > > SUBROUTINE FOO(X, [other parameters], X) > DOUBLE PRECISION X(N) > > [rest of code] > ... I have had a similar experience many years ago on an IBM PC. In my case the calling routine did not have the same arguments at X when calling FOO. What happend? An intermittent error that was harder than hell to find. I don't know why compilers don't check for it, it seems that there is very little benefit for allowing it to exist if it is legal in Fortran 77. -Joe Burkley
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (10/23/90)
In article <2385@cod.NOSC.MIL> burkley@cod.NOSC.MIL (V. J. Burkley) writes: In article <11084@hubcap.clemson.edu> mjs@hubcap.clemson.edu (m j saltzman) writes: ... What happend? An intermittent error that was harder than hell to find. I don't know why compilers don't check for it, it ... The primary function of compilers is to generate executable code. There are tools which do full static checking of programs (across subroutine boundries), SOME such tools are: Fortran-lint: IPT 1096 East Meadow Circle, Palo Alto, CA 94303 415-494-7500. I've used it. Quite good. FORWARN Quibus Enterprises: Seems similar, from a promo blurb reading. Probably has slightly uglier reporting (one assumes the promo is as good as it gets). 217 356 8876. Primary focus is the PC market, but say unix versions are available. $1200 would appear to be the price, no discount structure info available. Flint(tm) Programming Research ltd: Seems like a much more powerful tool (from the promo lit) includes complexity metrics, X11 interface and all sorts of advisories about what constitutes good portable code (beyond standard(s) conformance). FAX 01 336 1151 voice 01-942-9242 FORCHECK Leiden University Box 9604 2300 RC Leiden The Netherlands 31-71-276804 Claims similar to IPT's product. Is said to be available on Suns and many other platforms. I have no personal experience with it. FLOPPY/FLOW From CERN. FLOPPY was posted to comp.sources.misc. Sun employees can get it via the usual internal anon ftp site. FLOW was not posted (and is the 'good part'). Note that call foo(x,x) is legal (conformant with ANSI X3.9-1978) or not, depending on code inside of subroutine foo. In order to allow standard conforming codes, one mustn't disallow the call without examining the callee. -- ---------------------------------------------------------------- Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043
hirchert@pluto.ncsa.uiuc.edu (Kurt Hirchert) (10/23/90)
In article <11084@hubcap.clemson.edu> mjs@hubcap.clemson.edu (m j saltzman) writes: >I discovered an error in a FORTRAN program I was modifying, which amounts >to the following: > > SUBROUTINE FOO(X, [other parameters], X) > DOUBLE PRECISION X(N) > > [rest of code] > >This compiled without error on a Sun (with the -u flag) and on ULTRICS. >Fortunately (?), the calling routine supplied the same argument in both >positions, so no error occurred during execution. > >Questions: Is this really legal FORTRAN 77? If so, is it useful for >anything? What are the semantics of a call to the routine with different >arguments, say FOO(Y, ..., Z)? If not, why don't common compilers >(at least these) detect the error? Other types of duplicate declarations >are detected. > >Thanks for any insight. > > Matthew Saltzman > mjs@clemson.edu This is _not_ legal FORTRAN 77. Since compilers on rather unlike machines failed to complain about it, I assume some vendor must have created a useful extension using that syntax and that other vendors then copied it. I have no idea what that extension might actually do. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
patrick@convex.COM (Patrick F. McGehearty) (10/23/90)
In article <11084@hubcap.clemson.edu> mjs@hubcap.clemson.edu (m j saltzman) writes: > > SUBROUTINE FOO(X, [other parameters], X) > ... >This compiled without error on a Sun (with the -u flag) and on ULTRICS. ...Could it be that both of these compilers derive from the original Berkeley ...Unix f77 compiler? The likely behavior on those compilers which ignore the error is to choose one argument (probably the later one) and use it throughout the subroutine. In any case, this looks like a clear programming error to me. A Convex compiler gives an error complaining X being declared twice and about the dummy argument appearing twice.
mjs@hubcap.clemson.edu (m j saltzman) (10/23/90)
In article <KHB.90Oct22115411@chiba.Eng.Sun.COM% khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: %In article <2385@cod.NOSC.MIL% burkley@cod.NOSC.MIL (V. J. Burkley) writes: % % In article <11084@hubcap.clemson.edu% mjs@hubcap.clemson.edu (m j saltzman) writes: %... % What happend? An intermittent error that was harder than hell to find. I % don't know why compilers don't check for it, it %... % %The primary function of compilers is to generate executable code. %There are tools which do full static checking of programs (across %subroutine boundries), SOME such tools are: %[list of products deleted] % %Note that % % call foo(x,x) % %is legal (conformant with ANSI X3.9-1978) or not, depending on code %inside of subroutine foo. In order to allow standard conforming codes, %one mustn't disallow the call without examining the callee. % Sure, I understand that. My complaint was that the SUBROUTINE statement with two identical _formal_ parameters wasn't caught. This doesn't require global static checking to recognize--it's just like a duplicate declaration. (Interestingly, DOUBLE PRECISION X,X doesn't generate an error either--although declaring the same variable with different types does. Now duplicate declaration of a variable with the same type is a benign error, but the duplicate parameter is not.) I don't think the question of whether SUBROUTINE FOO(X,X) can be conformant under any circumstances has been resolved yet. Although there are numerous ways to assign a sensible semantics to CALL FOO(X,X) (even if X is modified by FOO), I don't think there are any for SUBROUTINE FOO(X,X) (unless maybe X is write-only and calling is by value/return?). %-- %---------------------------------------------------------------- %Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM %SMI 2550 Garcia 12-33 | (415 336 2648) % Mountain View, CA 94043 And in article <107528@convex.convex.com% patrick@convex.COM (Patrick F. McGehearty) writes: %In article <11084@hubcap.clemson.edu% mjs@hubcap.clemson.edu (m j saltzman) writes: %> %> SUBROUTINE FOO(X, [other parameters], X) %> ... %>This compiled without error on a Sun (with the -u flag) and on ULTRICS. %...Could it be that both of these compilers derive from the original Berkeley %...Unix f77 compiler? %The likely behavior on those compilers which ignore the error is to choose %one argument (probably the later one) and use it throughout the subroutine. %In any case, this looks like a clear programming error to me. %A Convex compiler gives an error complaining X being declared twice and %about the dummy argument appearing twice. Yes, it was a programming error, and yes, the Sun compiler does exactly what you describe. Thanks to everyone who responded here, and by e-mail. Matthew Saltzman mjs@clemson.edu
fred@balzac.scd.ucar.edu (Fred Clare) (10/24/90)
In article <11084@hubcap.clemson.edu>, mjs@hubcap.clemson.edu (m j saltzman) writes: > I discovered an error in a FORTRAN program I was modifying, which amounts > to the following: > > SUBROUTINE FOO(X, [other parameters], X) > DOUBLE PRECISION X(N) > > [rest of code] > > This compiled without error on a Sun (with the -u flag) and on ULTRICS. > Fortunately (?), the calling routine supplied the same argument in both > positions, so no error occurred during execution. > > Questions: Is this really legal FORTRAN 77? If so, is it useful for > anything? What are the semantics of a call to the routine with different > arguments, say FOO(Y, ..., Z)? If not, why don't common compilers > (at least these) detect the error? Other types of duplicate declarations > are detected. > > Thanks for any insight. > > Matthew Saltzman > mjs@clemson.edu Section 15.9.3.6 of the Fortran standard states: If a subprogram reference causes a dummy argument in the referenced subprogram to become associated with another dummy argument in the referenced subprogram, neither dummy argument may become defined during execution of that subprogram. For example, if a subroutine is headed by SUBROUTINE XYZ (A,B) and is referenced by CALL XYZ (C,C) then the dummy arguments A and B each become associated with the same actual argument C and therefore with each other. Neither A nor B may become defined during this execution of subroutine XYZ or by procedures referenced by XYZ Fred Clare NCAR (National Center for Atmospheric Research) fred@ncar.ucar.edu