g95 bug ?

Did anyone encounter this before? This is on Debian 2.6.9. g95 is
compiled from source. Thanks a lot for your  time in advance.
------
g95 -c -m32 -msse3  Strains.f90 -o Strains.o
In file Strains.f90:130

do jnod=1,nlink
1
Error: End expression in DO loop at (1) must be a scalar INTEGER
make: *** [Strains.o] Error 1


--
FCC.

FCC <fcc509@netscape.net> writes:

>       do jnod=1,nlink
>                1
> Error: End expression in DO loop at (1) must be a scalar INTEGER
> make: *** [Strains.o] Error 1

Well, the first question that occurs to me is that the compiler
might be telling the truth.  I don't know that it is, but I don't
see enough data to tell.

In particular, I don't see the declarations and other context
suffficient to tell me what type and rank nlink is.  I need to
see actual code to be sure of that - not just assertions.  I
tend to believe compilers before I believe unverified assertions.
Not that compilers are always right... but they do have a tendency
to notice things that even well-trained eyes miss on occasion.

One possibility that occurs to me is that you might not be aware
that the error message is correct for f95.  (I don't know whether
nlink is of a type and rank that applies, but the error message
standing alone is correct).  In f77, DO variables and corresponding
loop expressions were allowed to be real or double precision.
This was made obsolescent in f90, and it was one of the few
features deleted in f95.

Most f95 compilers still implement all of the deleted features,
but they are not actually part of the standard any more.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

FCC wrote:

> Did anyone encounter this before? This is on Debian 2.6.9. g95 is
> compiled from source. Thanks a lot for your  time in advance.
> ------
> g95 -c -m32 -msse3  Strains.f90 -o Strains.o
> In file Strains.f90:130
>
>       do jnod=1,nlink
>                1
> Error: End expression in DO loop at (1) must be a scalar INTEGER
> make: *** [Strains.o] Error 1
>
>
Two obvious questions.
1)  How is nlink declared?  Is it a scalar integer?
2)  If it isn't declared, do you have an IMPLICIT NONE
statement in your program?

Errors complaining about variable type or arrayness almost
always depend on the declaration statements.  Without
seeing those, it's unlikely anyone can help.

I'd guess that the "(1)" in the error message means the
compiler is complained about the thing marked "1" in the
second line, which is likely to be the start of the nlink
variable, not the "1" before the comma.

Dick Hendrickson

Dick Hendrickson articulated on 12/15/04 18:08:

>FCC wrote:
>
>
> 
>Two obvious questions.
>1)  How is nlink declared?  Is it a scalar integer?
>2)  If it isn't declared, do you have an IMPLICIT NONE
>     statement in your program?
>
>Errors complaining about variable type or arrayness almost
>always depend on the declaration statements.  Without
>seeing those, it's unlikely anyone can help.
>
>I'd guess that the "(1)" in the error message means the
>compiler is complained about the thing marked "1" in the
>second line, which is likely to be the start of the nlink
>variable, not the "1" before the comma.
>
>Dick Hendrickson
>
>
>
Actually nlink was declared as a real(kind=8) variable (I don't quite
recall how I did such a stupid mistake, damn!)

Thanks for your and R. Maine's answers (and patience).

--
FCC.

In article <m1mzwf5w3r.fsf@mlmce0000l22801.local>,
Richard E Maine <nospam@see.signature> writes:
> FCC <fcc509@netscape.net> writes:
> 
>
> Well, the first question that occurs to me is that the compiler
> might be telling the truth.  I don't know that it is, but I don't
> see enough data to tell.
>
> In particular, I don't see the declarations and other context
> suffficient to tell me what type and rank nlink is.  I need to
> see actual code to be sure of that - not just assertions.  I
> tend to believe compilers before I believe unverified assertions.
> Not that compilers are always right... but they do have a tendency
> to notice things that even well-trained eyes miss on occasion.
>
> One possibility that occurs to me is that you might not be aware
> that the error message is correct for f95.  (I don't know whether
> nlink is of a type and rank that applies, but the error message
> standing alone is correct).  In f77, DO variables and corresponding
> loop expressions were allowed to be real or double precision.
> This was made obsolescent in f90, and it was one of the few
> features deleted in f95.
>
> Most f95 compilers still implement all of the deleted features,
> but they are not actually part of the standard any more.
>

--
Steve
http://troutmask.apl.washington.edu/~kargl/

In article <m1mzwf5w3r.fsf@mlmce0000l22801.local>,
Richard E Maine <nospam@see.signature> writes:
> FCC <fcc509@netscape.net> writes:
> 
>
> Well, the first question that occurs to me is that the compiler
> might be telling the truth.  I don't know that it is, but I don't
> see enough data to tell.
>
> In particular, I don't see the declarations and other context
> suffficient to tell me what type and rank nlink is.  I need to
> see actual code to be sure of that - not just assertions.  I
> tend to believe compilers before I believe unverified assertions.
> Not that compilers are always right... but they do have a tendency
> to notice things that even well-trained eyes miss on occasion.
>
> One possibility that occurs to me is that you might not be aware
> that the error message is correct for f95.  (I don't know whether
> nlink is of a type and rank that applies, but the error message
> standing alone is correct).  In f77, DO variables and corresponding
> loop expressions were allowed to be real or double precision.
> This was made obsolescent in f90, and it was one of the few
> features deleted in f95.
>
> Most f95 compilers still implement all of the deleted features,
> but they are not actually part of the standard any more.
>

As a side note, gfortran implements the F77 behavior but issues a
warning.  If you specify -std=f95 on the command line, you get an
error.

--
Steve
http://troutmask.apl.washington.edu/~kargl/