[comp.lang.fortran] Implicit parameters in Sun 1.3.1 Fortran: Bug

rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) (02/07/91)

We have recently installed Sun's fortran version 1.3.1 and one of my
users came across the following:

In the programme

	implicit real*8 (a-z)
	parameter (PI=3.14159)
	print *,dcos(PI)
	end

the compiler complains about a type mismatch for dcos. I don't mind too
much (serve him right for not using implicit undefined), and I can see
how it could come about (I suspect that the compiler treats parameter as
a macro definition; a suspicion strengthened by the fact that gdb
doesn't know anything about a variable pi), but I think that the code is
valid fortran. But then again, I haven't written fortran in 8 years, and
I checked in a fortran book not the ANSI standard, so maybe it really is
illegal. 
 
				Robert

khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/07/91)

In article <6004@idunno.Princeton.EDU> rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) writes:


   We have recently installed Sun's fortran version 1.3.1 and one of my
   users came across the following:

   In the programme

	   implicit real*8 (a-z)
	   parameter (PI=3.14159)
	   print *,dcos(PI)
	   end

   the compiler complains about a type mismatch for dcos. I don't mind too

works in v1.4.
--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043

t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) (02/08/91)

In article <6004@idunno.Princeton.EDU> rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) writes:
>We have recently installed Sun's fortran version 1.3.1 and one of my
>users came across the following:
>
>	implicit real*8 (a-z)
>	parameter (PI=3.14159)
>	print *,dcos(PI)
>	end
>
>the compiler complains about a type mismatch for dcos....

Common error: how about adding
	implicit real*8 (A-Z)
If you mix cases - beware that Fortran may mix them too!

john@ghostwheel.unm.edu (John Prentice) (02/08/91)

In article <1139@nikhefh.nikhef.nl> t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) writes:
>>We have recently installed Sun's fortran version 1.3.1 and one of my
>>users came across the following:
>>
>>	implicit real*8 (a-z)
>>	parameter (PI=3.14159)
>>	print *,dcos(PI)
>>	end
>>
>>the compiler complains about a type mismatch for dcos....
>
>Common error: how about adding
>	implicit real*8 (A-Z)
>If you mix cases - beware that Fortran may mix them too!

This shouldn't matter, Fortran is not supposed to be case sensitive,
at least for variable names (someone corrrect me if I am wrong).
I would make one comment however, it is unnecessary to use dcos instead
of cos.  Assuming that the compiler is working correctly (a big 
assumption with 1.3.1), the generic name should suffice.  As far as this
bug, you might try turning off the optimization.  We have had terrible
trouble with bugs in 1.3.1 when running with -fast or -O3 level
optimization.  Who knows, it might help!

John
--
John K. Prentice    john@unmfys.unm.edu (Internet)
Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA
Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA

maine@altair.dfrf.nasa.gov (Richard Maine) (02/08/91)

On 7 Feb 91 17:21:34 GMT, t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) said:

Geert> In article <6004@idunno.Princeton.EDU> rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) writes:
>We have recently installed Sun's fortran version 1.3.1 and one of my
>users came across the following:
>
>	implicit real*8 (a-z)
>	parameter (PI=3.14159)
>	print *,dcos(PI)
>	end
>
>the compiler complains about a type mismatch for dcos....

Geert> Common error: how about adding
Geert> 	implicit real*8 (A-Z)
Geert> If you mix cases - beware that Fortran may mix them too!

That possibility occured to me when I saw the original post, but testing
reveals that not to be the problem.  Interestingly enough, changing
the
    implicit real*8 (a-z)
to
    implicit double precision (a-z)
did fix it.  Of course, real*8 is non-standard, but Sun's compiler
accepts it in most places, and it certainly should have bitched if
it didn't like it here.

I think this one counts as a bug instead of a user error.  (A bug
fixed in version 1.4 according to Kieth's post, though I don't have
1.4 to verify first hand).

--
--
Richard Maine
maine@altair.dfrf.nasa.gov

ravi@earth.ce.nwu.edu (Ravi Sinha) (02/08/91)

In article <1139@nikhefh.nikhef.nl> t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) writes:
>In article <6004@idunno.Princeton.EDU> rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) writes:
>>	implicit real*8 (a-z)
			 ^^^
>>	parameter (PI=3.14159)
>>	print *,dcos(PI)
>>the compiler complains about a type mismatch for dcos....
>
>Common error: how about adding
>	implicit real*8 (A-Z)
>If you mix cases - beware that Fortran may mix them too!

Isn't Fortran NOT supposed to be case sensitive?  I think that this
behavior can not be characterized as any thing but a bug.  Since PI is 
not a CHARACTER variable, why should the case matter?

---------------------------------------------------------------------
Ravi Sinha			|  As usual, the opinions here 
Northwestern University		|  are mine, and only mine.
ravi@earth.ce.nwu.edu		|  Who'd want to claim these anyway?

dik@cwi.nl (Dik T. Winter) (02/08/91)

In article <3301@casbah.acns.nwu.edu> ravi@earth (Ravi Sinha) writes:
 > Isn't Fortran NOT supposed to be case sensitive?  I think that this
 > behavior can not be characterized as any thing but a bug.

It could not be marked a bug for such a reason.  The original program does not
conform to the Fortran 77 standard in its use of lower case.  The standard
talks about upper case only.  I know of compilers that happily reject the
program because of this.

Having said this, most compilers I know are case insensitive indeed, and
amongst them is the Sun compiler.  And indeed there is a bug in that compiler,
but not because it is case sensitive in this case (which it is not).
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

jlg@lanl.gov (Jim Giles) (02/09/91)

From article <1991Feb07.225518.22499@ariel.unm.edu>, by john@ghostwheel.unm.edu (John Prentice):
>> [...]
>>If you mix cases - beware that Fortran may mix them too!
> 
> This shouldn't matter, Fortran is not supposed to be case sensitive,
> at least for variable names (someone corrrect me if I am wrong).

Ok, you're wrong :-).  Fortran 77 (still the present standard) doesn't
say _anything_ about case.  So a conforming compiler may do anthing
it likes with nonconforming programs (like those that use lower case).

Now, Fortran Extended does specify that the language is not case
sensitive except in certain specific contexts (values of type CHARACTER
and comments).  Further, in the I/O interface, even some values of
type character are _not_ case sensitive (in fact, the only I/O control
character string that _is_ allowed to be case sensitive is the file
name specification).

Still, the example that started this is probably a bug in the compiler.
Sun Fortran is _not_ case sensitive (for identifiers anyway).

J. Giles

dik@cwi.nl (Dik T. Winter) (02/09/91)

Is it a bug?  I just read the message from Jim Giles, which was similar to
mine:  if you are mixing cases all bets are off in Fortran 77.  But Jim,
like me, assumed it was a bug, because the compiler is not case sensitive.
On reflection my opinion is that it is not a bug, whatever way you want
to read the standard.  The program uses 'REAL*8', but that is not in the
Fortran 77 standard!  The only type specifier that allows a length
according to the standard is 'CHARACTER'.  Of course many compilers allow
length specifications on other types as well, but if you use them, again,
all bets are off.  (For instance: can you use REAL*5?  Perfectly legal in
ICL Fortran!)  And there are indeed Fortran 77 compilers around that do
not allow a length specification for type 'REAL' and 'INTEGER' and 'COMPLEX'.
(I just tried.)  As the original poster said, the problem goes away if
'DOUBLE PRECISION' is used in stead of 'REAL*8'.  So it is not a bug, but
a feature.  This is a 'Quality of implementation' issue.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

john@ghostwheel.unm.edu (John Prentice) (02/09/91)

In article <2920@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>Is it a bug?  I just read the message from Jim Giles, which was similar to
>mine:  if you are mixing cases all bets are off in Fortran 77.  But Jim,
>like me, assumed it was a bug, because the compiler is not case sensitive.
>On reflection my opinion is that it is not a bug, whatever way you want
>to read the standard. 

What can one say?  Thank God for Fortran Extended.

John

--
John K. Prentice    john@unmfys.unm.edu (Internet)
Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA
Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA

wsb@boise.Eng.Sun.COM (Walt Brainerd) (02/12/91)

In article <1991Feb09.075938.23229@ariel.unm.edu>, john@ghostwheel.unm.edu (John Prentice) writes:
> 
> What can one say?  Thank God for Fortran Extended.
> 
Amen, but--

the following is the first sentence from the document that describes
the language some of you (and X3) are calling "Fortran Extended"?
[What are you going to call the next version--"Fortran Extended Extended"?]

   This International Standard specifies the form
   and establishes the interpretation of programs expressed
   in the Fortran language
   (known informally as "Fortran 90").
--
Walt Brainerd        Sun Microsystems, Inc.
wsb@eng.sun.com      MS MTV 5-40
                     Mountain View, CA 94043
                     415/336-5991

jlg@lanl.gov (Jim Giles) (02/12/91)

From article <2920@charon.cwi.nl>, by dik@cwi.nl (Dik T. Winter):
> Is it a bug?  I just read the message from Jim Giles, which was similar to
> mine:  if you are mixing cases all bets are off in Fortran 77.  But Jim,
> like me, assumed it was a bug, because the compiler is not case sensitive.
> On reflection my opinion is that it is not a bug, whatever way you want
> to read the standard.

Point taken.  It is not a bug vis-a-vis the standard because the
program in question is non-standard - so the compiler may do anything
with it and still be a standard conforming compiler.

However, I still think it is a bug.  It is not a "standard compliance"
bug.  It is bug in the sense that it doesn't comply with the supplimentary
capabilities (above and beyond the standard) which the vendor claims
to support.  From both the vendor's and the user's point of view, this
can be just as severe a fault as non-compliance with the standard.

J. Giles