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 94043t19@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