davison@menudo.uh.edu (Dan Davison) (04/19/91)
The Absoft Fortran compiler for the NeXT issues the warning:
error on line 1446 of sn.f: adjustable array is not a dummy argument
and line 1446 is a "return 1" statement at the end of a large
subroutine. The alleged adjustable array is declared:
v------dummy arg
subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*)
parameter (ndim=10000, mdim=50000,nchr=80)
dimension seq(mdim)
^-------------doesn't look adjustable to me
And no compiler thinks it is an adjustable array, except Absoft.
Changing the dimension to be seq(50000) doesn't change the compiler's
mind [sic].
Some experimentation reveals that this error message can be eliminated
by putting the alleged adjustable array in common, but I'd like to
know what this compiler is drinking. This code compiles without
complaint on Suns (we know how amazing that is in and of itself), PCs
(RM and Lahey), Crays (CFT and CFT77), VAX/VMS and MIPS. What could
be going on here? Any insights would be appreciated.
Beware: the Absoft compiler thinks LSeq and Lseq are different
variables, surely a novel interpretation of the standard. Guess they
don't know how to fold case. It also obeys the Feldman/Unix Brain
Damage and doesn't generate a list file.
thanks very much,
dan
--
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU
Disclaimer: As always, I speak only for myself, and, usually, only to
myself.roth@oasys.dt.navy.mil (Pete Roth) (04/19/91)
In article <1991Apr18.223457.23190@menudo.uh.edu> davison@menudo.uh.edu (Dan Davison) writes: >The Absoft Fortran compiler for the NeXT issues the warning: > > error on line 1446 of sn.f: adjustable array is not a dummy argument > [...] > v------dummy arg > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > parameter (ndim=10000, mdim=50000,nchr=80) > dimension seq(mdim) > ^-------------doesn't look adjustable to me Since you've dimensioned seq properly elsewhere, and you _know_ what the maximum dimension is (mdim), how about writing the code like subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) parameter (ndim=10000, mdim=50000,nchr=80) dimension seq(1) ^-------------all the compiler _should_ need to know since i presume that the call statement to seqin is really of the form real a( BIGNUM ) ... iseq = ndim + 1 ! address of the seq array in a ... call seqin( ..., a(iseq), ... ) Of course, this doesn't answer your question about the compiler, but it may get you going again... - - - - - - - - - - - - - - - - - - - - - - - - - - Peter N Roth roth@oasys.dt.navy.mil Objects in this office are closer than they appear.
ddh@hare.cdc.com (Dan Horsfall) (04/20/91)
In article <7188@oasys.dt.navy.mil>, roth@oasys.dt.navy.mil (Pete Roth) writes: > In article <1991Apr18.223457.23190@menudo.uh.edu>, davison@menudo.uh.edu (Dan Davison) writes: > [...] > > v------dummy arg > > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > > parameter (ndim=10000, mdim=50000,nchr=80) > > dimension seq(mdim) > > ^-------------doesn't look adjustable to me > > Since you've dimensioned seq properly elsewhere, and you _know_ what the > maximum dimension is (mdim), how about writing the code like > > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > parameter (ndim=10000, mdim=50000,nchr=80) > dimension seq(1) > ^-------------all the compiler _should_ need to know (gently, he suggests) No, please don't do it that way. That's what dimension seq(*) was designed for. Altho many compilers will treat (1) the same way, those that are capable of array bounds checking ("abc") will gag on (1) when (*) is intended. This could degenerate into a style war, which is NOT intended. -- Horse + Control Data Corporation Dan Horsfall +1-612-482-4622 + 4201 Lexington Ave North Internet ddh@dash.udev.cdc.com + Arden Hills MN 55126 USA
vsnyder@jato.jpl.nasa.gov (Van Snyder) (04/20/91)
In article <7188@oasys.dt.navy.mil> roth@oasys.dt.navy.mil (Pete Roth) writes: >In article <1991Apr18.223457.23190@menudo.uh.edu> davison@menudo.uh.edu (Dan Davison) writes: >>The Absoft Fortran compiler for the NeXT issues the warning: >> >> error on line 1446 of sn.f: adjustable array is not a dummy argument >> >[...] >> v------dummy arg >> subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) >> parameter (ndim=10000, mdim=50000,nchr=80) >> dimension seq(mdim) >> ^-------------doesn't look adjustable to me > >Since you've dimensioned seq properly elsewhere, and you _know_ what the >maximum dimension is (mdim), how about writing the code like > > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > parameter (ndim=10000, mdim=50000,nchr=80) > dimension seq(1) > ^-------------all the compiler _should_ need to know >[stuff deleted] >- - - - - - - - - - - - - - - - - - - - - - - - - - >Peter N Roth roth@oasys.dt.navy.mil >Objects in this office are closer than they appear. It's a bad idea to use "1" for the dimension of a formal argument. You should use "*" instead. The reason is that on machines with crazy addressing (read 80x86), the compiler needs to know whether the upper bound is fixed or variable. If it's variable, strenuous gymnastics are necessary, e.g. on an 8086 when the array requires more than 65k bytes. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
rolfe@dsuvax.uucp (Timothy J. Rolfe) (04/20/91)
In <7188@oasys.dt.navy.mil> roth@oasys.dt.navy.mil (Pete Roth) writes: >In article <1991Apr18.223457.23190@menudo.uh.edu> davison@menudo.uh.edu (Dan Davison) writes: >>The Absoft Fortran compiler for the NeXT issues the warning: >> >> error on line 1446 of sn.f: adjustable array is not a dummy argument >> >[...] >> v------dummy arg >> subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) >> parameter (ndim=10000, mdim=50000,nchr=80) >> dimension seq(mdim) >> ^-------------doesn't look adjustable to me >Since you've dimensioned seq properly elsewhere, and you _know_ what the >maximum dimension is (mdim), how about writing the code like > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > parameter (ndim=10000, mdim=50000,nchr=80) > dimension seq(1) > ^-------------all the compiler _should_ need to know Actually, make that "dimension seq(*)", which is how you declare the thing to be "dimensioned -- don't bug me with bounds checking".
davison@menudo.uh.edu (Dan Davison) (04/20/91)
A number of folks have suggested that the problem I posted about
What does "adjustable array is not a dummy argument" mean? might be
cured by changing the declaration of the array from
dimension seq(mdim)
to
dimension seq(1)
or even
dimension seq(*)
Where mdim is a parameterized variable. Nope, it doesn't do any good.
I guess it's just a crufy compiler...
Further clues would be welcome....
thanks very much,
dan davison
--
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU
Disclaimer: As always, I speak only for myself, and, usually, only to
myself.maine@altair.dfrf.nasa.gov (Richard Maine) (04/20/91)
On 19 Apr 91 11:55:15 GMT, roth@oasys.dt.navy.mil (Pete Roth) said: Pete> In article <1991Apr18.223457.23190@menudo.uh.edu> davison@menudo.uh.edu (Dan Davison) writes: >The Absoft Fortran compiler for the NeXT issues the warning: > > error on line 1446 of sn.f: adjustable array is not a dummy argument > > v------dummy arg > subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) > parameter (ndim=10000, mdim=50000,nchr=80) > dimension seq(mdim) > ^-------------doesn't look adjustable to me I know nothing of substance about that compiler, but my guess would be that it doesn't like the alternate return (the "*" in the subroutine statement). Note that the syntax of the alternate return is simillar to that of an adjustable array. Not identical, but it might be simillar enough to confuse the compiler. The syntax does look correct as far as I recall (I don't use alternate returns myself, so I'm not real up on them). To test this theory, try taking the ",*" out of the arg list just to see if compilation goes further. That won't solve the problem, but it might help determine wherin the problem lies. Pete> Since you've dimensioned seq properly elsewhere, and you _know_ what the Pete> maximum dimension is (mdim), how about writing the code like Pete> subroutine seqin(nf,lf,Outfl,Termnl,seqid,min,n,seq,ic,nmax,*) Pete> parameter (ndim=10000, mdim=50000,nchr=80) Pete> dimension seq(1) Pete> ^-------------all the compiler _should_ need to know Well, you could try, but the original looks very innocuous in this area. I'd bet (but not too much :-)) that this wouldn't help. Also note that while it is *very* common practice to use dimensions of 1 in this way, it is not strictly standard. And yes, I have seen compilers where it mattered. For instance, some compilers might refuse to allow subscripts larger than 1 if the array is declared like this, giving either compile-time or run-time errors, depending on specifics. I think I recall a CDC compiler where this worked, but made run-time array-bounds checking useless, for instance. -- -- Richard Maine maine@altair.dfrf.nasa.gov
dlindsle@afit.af.mil (David T. Lindsley) (05/03/91)
In article <7188@oasys.dt.navy.mil> roth@oasys.dt.navy.mil (Pete Roth) writes: > dimension seq(1) > ^-------------all the compiler _should_ need to know As has already been pointed out, this creates problems if your compiler does array bounds checking. Here's a further wrinkle. If this array is declared within a common block, most compilers will say "common block FOO has different sizes in module BAR and module BLETCH". (Naturally.) But here's a REALLY good one: If you try using _dbx_ (BSD4.3) on this code, it will show all array entries, even those with subscripts higher than one. But -- all but the first (i.e. seq(1)) will show up as zero. And if you declare the array as seq(*), you won't be able to examine the entries whose subscripts are greater than one. I don't know how pervasive this problem is -- I haven't tried to duplicate it on any of our other Un*x debuggers. (Maybe Sun's _dbx_ doesn't suffer from this problem?) I *am* fairly certain that the problem does not affect VMS Fortran/VAX DEBUG. -- Dave Lindsley #24601# OPINIONS. MINE. dlindsle@blackbird.afit.af.mil (The words don't come no smaller.) "If you don't succeed at first -- transform your data!" (me)
vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/03/91)
In article <1991May02.183125.4093@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >In article <7188@oasys.dt.navy.mil> roth@oasys.dt.navy.mil (Pete Roth) writes: > >> dimension seq(1) >> ^-------------all the compiler _should_ need to know >[...] >But here's a REALLY good one: >If you try using _dbx_ (BSD4.3) on this code, it will show all array >entries, even those with subscripts higher than one. But -- all but >the first (i.e. seq(1)) will show up as zero. >And if you declare the array as seq(*), you won't be able to examine >the entries whose subscripts are greater than one. > >I don't know how pervasive this problem is -- I haven't tried to >duplicate it on any of our other Un*x debuggers. (Maybe Sun's _dbx_ >doesn't suffer from this problem?) I *am* fairly certain that the >problem does not affect VMS Fortran/VAX DEBUG. > >-- >Dave Lindsley #24601# OPINIONS. MINE. >dlindsle@blackbird.afit.af.mil (The words don't come no smaller.) > "If you don't succeed at first -- transform your data!" (me) The last time I used Sun's dbx, on a 3/160 about two years ago, it suffered from this disease. The problem is that dbx is a C debugger. It doesn't know squat about Fortran. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp