g77 compliance?
Charles Banas
thread I started on c.l.c, and that it pertains to a Fortran routine
I'm trying to port. This is partly in regards to that effort. (I
again apologize for my earlier cross-post, as the post I replied to
requested followups here.)
My first question is how compliant g77 is to the Fortran standards?
Which standard is it supposedly the "most compliant" to? The reason I
ask is because code that compiles with IFC will not compile with g77,
and vice-versa, and I have a good deal of code that is supposed to be
valid F77 but uses obscure extensions to F95! So some clarification
on g77's compliance would be helpful.
Secondly, I'm curious about array addressing. I understand that
arrays are 1-based (unlike C's 0-based arrays), and that
multi-dimensional arrays are stored in contiguous memory (whereas C
stores them in arrays of pointers to arrays).
My problem is that I've encounted an EQUIVALENCE that addresses a
two-dimensional array (for example, ZA(5,2) ) as a one-dimensional
array as in:
EQUIVALENCE ( Z4A1, ZA(6) )
I'm quite unclear how this maps and how it actually appears in memory.
Thank you for your time.
-- Charles Banas
Sheldon Simms
> My question here is two-fold. A few of you may have noticed the
> thread I started on c.l.c, and that it pertains to a Fortran routine
> I'm trying to port. This is partly in regards to that effort. (I
> again apologize for my earlier cross-post, as the post I replied to
> requested followups here.)
>
> My first question is how compliant g77 is to the Fortran standards?
> Which standard is it supposedly the "most compliant" to? The reason I
> ask is because code that compiles with IFC will not compile with g77,
> and vice-versa, and I have a good deal of code that is supposed to be
> valid F77 but uses obscure extensions to F95! So some clarification
> on g77's compliance would be helpful.
The code *does* compile with g77, once the equivalence statements
have been altered. I don't know if there is a switch for g77 that
makes it accept one-dimensional subscripting of two-dimensional
arrays in equivalence statements or not.
> Secondly, I'm curious about array addressing. I understand that
> arrays are 1-based (unlike C's 0-based arrays), and that
> multi-dimensional arrays are stored in contiguous memory (whereas C
> stores them in arrays of pointers to arrays).
>
> My problem is that I've encounted an EQUIVALENCE that addresses a
> two-dimensional array (for example, ZA(5,2) ) as a one-dimensional
> array as in:
> EQUIVALENCE ( Z4A1, ZA(6) )
>
> I'm quite unclear how this maps and how it actually appears in memory.
Charles, here is my "rewrite" of the equivalence statements in this
code. If you have moved to a gcc environment then I would suggest just
compiling the subroutine with g77 and linking it to the rest of the
program. The problem with rewriting it in C++ is that you will have to
be very ,very careful to preserve the function of the routine. It's
easy to make a mistake when transcribing hundreds of lines of code
like
IMN = 2
IMX = LX0
30 IX = ( IMN + IMX ) / 2
IF ( UK .GE. X(IX) ) GO TO 40
IMX = IX
GO TO 50
What ever you decide to do, perhaps this will help you. You can just
replace the equivalence statements in the code with these and it should
compile. If you really are going to try to get into the code and
understand it completely, you would probably find the program isn't
really relying on (most of) this aliasing anyway and a lot of these
equivalence statements could be removed.
*
EQUIVALENCE (Z3A1, ZA(1,1)), (Z3A2, ZA(2,1)), (Z3A3, ZA(3,1))
EQUIVALENCE (Z3A4, ZA(4,1)), (Z3A5, ZA(5,1))
EQUIVALENCE (Z4A1, ZA(1,2)), (Z4A2, ZA(2,2)), (Z4A3, ZA(3,2))
EQUIVALENCE (Z4A4, ZA(4,2)), (Z4A5, ZA(5,2))
EQUIVALENCE (Z3B1, ZB(1,1)), (Z3B2, ZB(1,2)), (Z3B3, ZB(1,3))
EQUIVALENCE (Z3B4, ZB(1,4)), (Z3B5, ZB(1,5))
EQUIVALENCE (Z4B1, ZB(2,1)), (Z4B2, ZB(2,2)), (Z4B3, ZB(2,3))
EQUIVALENCE (Z4B4, ZB(2,4)), (Z4B5, ZB(2,5))
EQUIVALENCE (ZA2B2, ZAB(1,1)), (ZA3B2, ZAB(2,1))
EQUIVALENCE (ZA4B2, ZAB(3,1))
EQUIVALENCE (ZA2B3, ZAB(1,2)), (ZA3B3, ZAB(2,2))
EQUIVALENCE (ZA4B3, ZAB(3,2))
EQUIVALENCE (ZA2B4, ZAB(1,3)), (ZA3B4, ZAB(2,3))
EQUIVALENCE (ZA4B4, ZAB(3,3))
EQUIVALENCE (ZX33, ZX(2,2)), (ZX43, ZX(3,2))
EQUIVALENCE (ZX34, ZX(2,3)), (ZX44, ZX(3,3))
EQUIVALENCE (ZY33, ZY(2,2)), (ZY43, ZY(3,2))
EQUIVALENCE (ZY34, ZY(2,3)), (ZY44, ZY(3,3))
EQUIVALENCE (ZXY33, ZXY(2,2)), (ZXY43, ZXY(3,2))
EQUIVALENCE (ZXY34, ZXY(2,3)), (ZXY44, ZXY(3,3))
EQUIVALENCE (LX0, ZX(1,1)), (LXM1, ZX(4,1))
EQUIVALENCE (LXM2, ZX(1,4)), (LXP1, ZX(4,4))
EQUIVALENCE (LY0, ZY(1,1)), (LYM1, ZY(4,1))
EQUIVALENCE (LYM2, ZY(1,4)), (LYP1, ZY(4,4))
EQUIVALENCE (IX, ZXY(1,1)), (IY, ZXY(4,1))
EQUIVALENCE (IXPV, ZXY(1,4)), (IYPV, ZXY(4,4))
EQUIVALENCE (P00, Z33), (P01, ZY33), (P10, ZX33), (P11, ZXY33)
*
EQUIVALENCE (JXM2, JX1), (JYM2, JY1)
EQUIVALENCE (IMN, JX), (IMX, JY),
EQUIVALENCE (UK, DX), (VK, DY)
EQUIVALENCE (A1, A5, B1, B5, ZX(2,1), A, Q0)
EQUIVALENCE (A2, ZX(1,2), B, Q1), (A4, ZX(4,2), C, Q2)
EQUIVALENCE (X2, ZX(3,1), A3SQ), (X4, ZX(1,3))
EQUIVALENCE (X5, ZX(4,3)), (Y5, ZX(3,4), P02)
EQUIVALENCE (Y2, ZX(2,4)), (Y4, ZY(3,1), B3SQ)
EQUIVALENCE (B2, ZY(2,1), D, Q3), (B4, ZY(2,4), E)
EQUIVALENCE (W2, WY2, W4), (W3, WY3, W1, W5)
EQUIVALENCE (WX2, ZXY(2,4))
EQUIVALENCE (WX3, ZXY(3,4))
EQUIVALENCE (Z23, ZY(1,2), P03)
EQUIVALENCE (Z24, ZY(4,2), P12)
EQUIVALENCE (Z32, ZY(1,3), P13)
EQUIVALENCE (Z34, ZY(4,3), P20)
EQUIVALENCE (Z35, ZY(3,4), P21)
EQUIVALENCE (Z42, ZXY(2,1), P22)
EQUIVALENCE (Z43, ZXY(1,2), P23)
EQUIVALENCE (Z44, ZXY(3,1), P30)
EQUIVALENCE (Z45, ZXY(4,2), P31)
EQUIVALENCE (Z53, ZXY(1,3), P32)
EQUIVALENCE (Z54, ZXY(4,3), P33)
*
Richard Maine
> My first question is how compliant g77 is to the Fortran standards?
Very. As are most compilers.
> Which standard is it supposedly the "most compliant" to?
Lets forget the "most" part; that's not a very relevant term here.
G77 complies with the Fortran 77 standard (this, its name). Like
pretty much every real Fortran 77 compiler, it also allows some
extensions to Fortran 77. Allowing extensions does not make
a compiler noncompliant with the standard.
> The reason I
> ask is because code that compiles with IFC will not compile with g77,
Well, current versions of IFC are f95 compilers. F95 has *LOTS* of
things that aren't valid f77. F95 is a superset of f77. If you have
valid f77 code, it is also valid f95 code, but the converse is not
true.
> and vice-versa, and I have a good deal of code that is supposed to be
> valid F77 but uses obscure extensions to F95!
That statement contradicts itself. If code uses extensions to f95,
it certainly is not valid f77.
> Secondly, I'm curious about array addressing. I understand that
> arrays are 1-based (unlike C's 0-based arrays),
Not necessarily so. 1-basing is the default, but you can declare
otherwise. (Well, in f77 and later. As noted below, this appears
to be f66 code.)
> and that
> multi-dimensional arrays are stored in contiguous memory (whereas C
> stores them in arrays of pointers to arrays).
Well, C can do things any of several different ways. It does not
necessarily use arrays of pointers to arrays, but this is about
Fortran, not C, so lets skip over that.
> My problem is that I've encounted an EQUIVALENCE that addresses a
> two-dimensional array (for example, ZA(5,2) ) as a one-dimensional
> array as in:
> EQUIVALENCE ( Z4A1, ZA(6) )
>
> I'm quite unclear how this maps and how it actually appears in memory.
I had forgotten that this was ever legal at all, but someone here
reminded me of it a few days ago. This was legal in f66, but *NOT* in
f77 or anything later. The f77 standard Appendix A has a list of 24
conflicts between f66 and f77. This is item 7 in that list. What you
have is apparently f66 code, not f77....or anyway code written by
someone used to f66, perhaps using an f77 compiler that accepted it as
an extension. Some f77 and later compilers might accept it, but that
is a compiler extension. Standard-conforming f77 compilers are not
required to.
In f66, this meant that Z4A1 was equivalenced with the 6th element
of ZA in array element order. Array element order goes down the first
column, then down the 2nd, etc. For arrays of more than 2
dimensions, the index of the earliest dimensions vary most
rapidly.
There are a lot more conflicts between f66 and f77 than there were
between subsequent revisions of the standard. (See the list of
24 items in the f77 standard). Of course, much code from the f66
era didn't conform to any standard. Sensitivity to standards
issues is a lot higher today than it was then.
--
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
Richard Maine
> The f77 standard Appendix A has a list of 24
> conflicts between f66 and f77. This is item 7 in that list.
Excuse me. Item 5. Crossed my eyes or something when looking at
it before. Item 7 is the extended range of a DO loop.
Sheldon Simms
> grey...@the-junkyard.net (Charles Banas) writes:
>
>> My problem is that I've encounted an EQUIVALENCE that addresses a
>> two-dimensional array (for example, ZA(5,2) ) as a one-dimensional
>> array as in:
>> EQUIVALENCE ( Z4A1, ZA(6) )
>>
>> I'm quite unclear how this maps and how it actually appears in memory.
>
> I had forgotten that this was ever legal at all, but someone here
> reminded me of it a few days ago. This was legal in f66, but *NOT* in
> f77 or anything later.
At the moment, my knowledge of Fortran comes from reading the
IBM 704 Fortran Reference Manual which states:
EQUIVALENCE (a, b, c, ...), (d, e, f, ...), ...
where a,b,c,d,e,f, ... are variables optionally followed by
a single unsigned fixed point constant in parentheses.
^^^^^^
And goes on to say:
In an EQUIVALENCE statement the meaning of C(5), for example,
is "the 4th storage location in the object program after the
cell containing C, or (if C is an array) after C(1) or C(1,1)
or C(1,1,1)".
Jan C. Vorbrüggen
> IBM 704 Fortran Reference Manual which states:
Rmove that item immediately from your view, and NEVER use it again. It's
about as similar to current Fortran as Chaucer's English is to what you
are speaking.
Various books have been recommended here (see Metcalf's regularly posted
list, ot the resources at www.fortran.com). At least, read up on the
current language using, for instance, the Compaq/HP documentation freely
available on the web, at http://h18009.www1.hp.com/fortran/docs/lrm/dflrm.htm
and other places linked from there.
Jan
Steve Lionel
wrote:
>Well, current versions of IFC are f95 compilers. F95 has *LOTS* of
>things that aren't valid f77. F95 is a superset of f77. If you have
>valid f77 code, it is also valid f95 code,[snip]
... unless your code uses features that were deleted in F95, such as PAUSE and
ASSIGN. However, I don't know of any F95 compilers that actually removed
support for deleted features.
Compaq Visual Fortran Support: http://compaq.com/fortran/support/visual.html
Intel Fortran Support: http://developer.intel.com/software/products/support/
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Fortran and Compaq Visual Fortran:
http://intel.com/IDS/forums/fortran
Richard Maine
>> At the moment, my knowledge of Fortran comes from reading the
>> IBM 704 Fortran Reference Manual which states:
>
> Rmove that item immediately from your view, and NEVER use it again. It's
> about as similar to current Fortran as Chaucer's English is to what you
> are speaking.
Nah. Send it to me. And I'll gladly take any original Chaucerian
manuscripts you might have around also. My wife can even manage to
read Chaucer without translations. I'm not sure I should allow my
daughter to (though I suppose that by the time she can manage, it will
be ok). :-)
Both have significant historical value, though I don't think the IBM
704 manuals have yet caught up with Chaucer in that regard.
Sheldon Simms
> Jan C. Vorbrüggen <jvorbr...@mediasec.de> writes:
>
>>> At the moment, my knowledge of Fortran comes from reading the
>>> IBM 704 Fortran Reference Manual which states:
>>
>> Rmove that item immediately from your view, and NEVER use it again. It's
>> about as similar to current Fortran as Chaucer's English is to what you
>> are speaking.
>
> Nah. Send it to me. And I'll gladly take any original Chaucerian
> manuscripts you might have around also.
Well having read the manual, I knew what the OP's problem was, and
could even fix it, without having written a single line of Fortran
in my life :-)
But seriously, I know it's ancient and not really applicable to
programming in Fortran in 2003. I read the manual for fun, not knowing
anything about Fortran, and found it interesting. That's the only reason
I'm reading this group at all.
Sorry Richard, it's just a PDF acquired through googling.
-Sheldon
Charles Banas
<snip my drivel>
>
> The code *does* compile with g77, once the equivalence statements
> have been altered. I don't know if there is a switch for g77 that
> makes it accept one-dimensional subscripting of two-dimensional
> arrays in equivalence statements or not.
>
I haven't been able to find one - hence my decision for a rewrite.
>
> Charles, here is my "rewrite" of the equivalence statements in this
> code. If you have moved to a gcc environment then I would suggest just
> compiling the subroutine with g77 and linking it to the rest of the
> program. The problem with rewriting it in C++ is that you will have to
> be very ,very careful to preserve the function of the routine. It's
> easy to make a mistake when transcribing hundreds of lines of code
> like
>
Which is something I was prepared to do. This isn't the first time
I've rewritten a complex routine in C++, so I'm fairly confident that
I would make few mistakes. (I wouldn't dare say /no/ mistakes.)
>
> What ever you decide to do, perhaps this will help you. You can just
> replace the equivalence statements in the code with these and it should
> compile. If you really are going to try to get into the code and
> understand it completely, you would probably find the program isn't
> really relying on (most of) this aliasing anyway and a lot of these
> equivalence statements could be removed.
>
I would have done that myself had I been more familiar with arrays.
But thank you very much. This will save me /days/ in work.
-- Charles Banas
Charles Banas
> grey...@the-junkyard.net (Charles Banas) writes:
>
> > My first question is how compliant g77 is to the Fortran standards?
>
> Very. As are most compilers.
>
> > Which standard is it supposedly the "most compliant" to?
>
> Lets forget the "most" part; that's not a very relevant term here.
> G77 complies with the Fortran 77 standard (this, its name). Like
> pretty much every real Fortran 77 compiler, it also allows some
> extensions to Fortran 77. Allowing extensions does not make
> a compiler noncompliant with the standard.
>
I understand that. I should have been more concise.
> > The reason I
> > ask is because code that compiles with IFC will not compile with g77,
>
> Well, current versions of IFC are f95 compilers. F95 has *LOTS* of
> things that aren't valid f77. F95 is a superset of f77. If you have
> valid f77 code, it is also valid f95 code, but the converse is not
> true.
>
Which is what perplexed me. The code I was given was labelled as
being "Fortran 77 code" but it only compiled in an F95 environment.
> > and vice-versa, and I have a good deal of code that is supposed to be
> > valid F77 but uses obscure extensions to F95!
>
> That statement contradicts itself. If code uses extensions to f95,
> it certainly is not valid f77.
>
See above. I was clearly misled.
> > Secondly, I'm curious about array addressing. I understand that
> > arrays are 1-based (unlike C's 0-based arrays),
>
> Not necessarily so. 1-basing is the default, but you can declare
> otherwise. (Well, in f77 and later. As noted below, this appears
> to be f66 code.)
>
> > and that
> > multi-dimensional arrays are stored in contiguous memory (whereas C
> > stores them in arrays of pointers to arrays).
>
> Well, C can do things any of several different ways. It does not
> necessarily use arrays of pointers to arrays, but this is about
> Fortran, not C, so lets skip over that.
>
I was pointing out my perspective based on my knowledge, but yes, I
agree.
> > My problem is that I've encounted an EQUIVALENCE that addresses a
> > two-dimensional array (for example, ZA(5,2) ) as a one-dimensional
> > array as in:
> > EQUIVALENCE ( Z4A1, ZA(6) )
> >
> > I'm quite unclear how this maps and how it actually appears in memory.
>
> I had forgotten that this was ever legal at all, but someone here
> reminded me of it a few days ago. This was legal in f66, but *NOT* in
> f77 or anything later. The f77 standard Appendix A has a list of 24
> conflicts between f66 and f77. This is item 7 in that list. What you
> have is apparently f66 code, not f77....or anyway code written by
> someone used to f66, perhaps using an f77 compiler that accepted it as
> an extension. Some f77 and later compilers might accept it, but that
> is a compiler extension. Standard-conforming f77 compilers are not
> required to.
>
Which is frustrating for me to say the least, since I didn't want to
change the code unless it was part of a rewrite.
> In f66, this meant that Z4A1 was equivalenced with the 6th element
> of ZA in array element order. Array element order goes down the first
> column, then down the 2nd, etc. For arrays of more than 2
> dimensions, the index of the earliest dimensions vary most
> rapidly.
>
So Z4A1 maps to ZA(1,2)? That's what I wasn't clear on. I am now. :P
> There are a lot more conflicts between f66 and f77 than there were
> between subsequent revisions of the standard. (See the list of
> 24 items in the f77 standard). Of course, much code from the f66
> era didn't conform to any standard. Sensitivity to standards
> issues is a lot higher today than it was then.
I thought Fortran V was a ratified standard?
Well, back to the history books. I must have missed something.
But you are right - this code was written in 1973 for a Univac.
-- Charles Banas
Ken Fairfield
[big snip]
> Which is what perplexed me. The code I was given was labelled as
> being "Fortran 77 code" but it only compiled in an F95 environment.
[bigger snip]
> But you are right - this code was written in 1973 for a Univac.
Observing the obvious then, a code written in 1973 for a Univac
could not have been Fortran 77 code given that standard was
not published until 1978. :-}
-Ken
--
I don't speak for Intel, Intel doesn't speak for me...
Ken Fairfield
D1C Automation VMS System Support
who: kenneth dot h dot fairfield
where: intel dot com
Glen Herrmannsfeldt
"Ken Fairfield" <My.Ful...@intel.com> wrote in message
news:bobnbr$v69$1...@news01.intel.com...
> Charles Banas wrote:
> [big snip]
> > Which is what perplexed me. The code I was given was labelled as
> > being "Fortran 77 code" but it only compiled in an F95 environment.
> [bigger snip]
> > But you are right - this code was written in 1973 for a Univac.
> Observing the obvious then, a code written in 1973 for a Univac
> could not have been Fortran 77 code given that standard was
> not published until 1978. :-}
It might be that some things were leaking out of the standard, and being
implemented in compilers even before 1977.
It wouldn't be "standard Fortran 77 code", but maybe "code containing
features from the possible Fortran 77 standard."
WATFIV had CHARACTER variables pretty much like the standard, in 1973.
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote in message news:<m34qxja...@altair.dfrc.nasa.gov>...
>> grey...@the-junkyard.net (Charles Banas) writes:
>> > My first question is how compliant g77 is to the Fortran standards?
>> Very. As are most compilers.
> As I suspected, but my experience tended to lean in other directions.
My experience is that in the large majority of cases, problems are
far more likely to arise from code that doesn't follow the standard
than from compilers that don't. Note that just because someone
claims that code conforms to a standard doesn't mean that it actually
does. I work quite regularly with simulator code from an major
aerospace corporation where every subroutine includes a comment
stating that it conforms to the Fortran 77 standard. It is quite obvious
that the code was written to coding standards that required such a
statement in the comments. It is equally obvious that there was no
requirement that the statement be true. The code doesn't even come
close to conformance - my guess is that the writers never had even
seen a copy of the standard or any book about it; they just knew that
they had to include that comment.
In this case, the code might have conformed to the f66 standard.
(Anyway it sounds like this part of it did). It is really hard to
find compilers that are fully f66-compliant today. Lots of code that
is f66 compliant is also f77 compliant, at least if one includes Annex
C (Hollerith) as part of f77. And most f77 (and even f90/f95)
compilers do implement Hollerith. But some other f66 features are a
lot harder to find in today's compilers. You might be able to find
a compiler today that implements the f66 extended range of DO, but
you'll probably have to search quite a bit.
Compilers do have bugs. Some have a lot more than others. But if
your experience leads you to suspect compiler conformance as a first
suspect, then...well...lets express it in an unbiased manner by saying
that your experience is a lot different than mine (perhaps because
your experience might be concentrated in compilers that I tend to avoid;
been using MS PS 4 a lot?)
> Which is what perplexed me. The code I was given was labelled as
> being "Fortran 77 code" but it only compiled in an F95 environment.
Well..it compiled it a particular F95 environment. Apparently that
particular f95 compiler accepts this particular feature as an extension.
This has a lot more to do with the particular compiler than with
whether the compiler conforms to f77, f95, or whatever.
> I thought Fortran V was a ratified standard?
No. In fact, I'm not even entirely sure what you would be
referring to as Fortran V. Some vendors used that terminology, but
there is no standard known either formally or informally by that name.
If I recall correctly, CDC might have referred to their Fortran 77
compiler as Fortran V. If so, that is a vendor's name for a
particular implementation, not a reference to any standard. Wouldn't
surprise me if some other vendors (perhaps including Univac, though my
experience with them is very old and very limitted) also used the
name, but just saying Fortran V isn't enough to identify it. The
relevant standard is what is informally known as Fortran 77 (or by its
various reference numbers such as ANSI X3.9-1978).
leslie
:
: I thought Fortran V was a ratified standard?
:
: Well, back to the history books. I must have missed something.
:
: But you are right - this code was written in 1973 for a Univac.
Univac's FORTRAN V was written by Computer Science Corporation:
http://www.cc.gatech.edu/gvu/people/randy.carpenter/folklore/v3n2.html
Unisys History Newsletter v3n2
''...Sperry Rand was also fortunate to have a good FORTRAN compiler and
some program conversion tools. The FORTRAN V compiler for the 1108,
written by Computer Sciences Corporation, produced very efficient
programs. At a meeting of Burroughs engineers discussing their
competitors, Robert Barton referred to it as "a polished masterpiece"
and another participant said: "You sit there and watch the code that
thing cranks out and just try to imagine assembly code that would be
written that well."...''
Univac FORTRAN V had such features as:
o PARAMETER
o INCLUDE
o DELETE
o FLD function for bit-twiddling; e.g.:
FLD (0,6,X) = FLD (30,6,Y)
Later, Jack Perrine's ATHENA Programming, Inc. took on the maintenance
of FORTRAN V until switching over to Forth work.
--Jerry Leslie
Note: les...@jrlvax.houston.rr.com is invalid for email
Charles Banas
> grey...@the-junkyard.net (Charles Banas) writes:
> > Richard Maine <nos...@see.signature> wrote in message news:<m34qxja...@altair.dfrc.nasa.gov>...
> >> grey...@the-junkyard.net (Charles Banas) writes:
>
> >> > My first question is how compliant g77 is to the Fortran standards?
> >> Very. As are most compilers.
> > As I suspected, but my experience tended to lean in other directions.
>
> My experience is that in the large majority of cases, problems are
> far more likely to arise from code that doesn't follow the standard
> than from compilers that don't. Note that just because someone
> claims that code conforms to a standard doesn't mean that it actually
> does. I work quite regularly with simulator code from an major
> aerospace corporation where every subroutine includes a comment
> stating that it conforms to the Fortran 77 standard. It is quite obvious
> that the code was written to coding standards that required such a
> statement in the comments. It is equally obvious that there was no
> requirement that the statement be true. The code doesn't even come
> close to conformance - my guess is that the writers never had even
> seen a copy of the standard or any book about it; they just knew that
> they had to include that comment.
>
this old code. I must admit i'm not the biggest fan of Fortran.
> In this case, the code might have conformed to the f66 standard.
> (Anyway it sounds like this part of it did). It is really hard to
> find compilers that are fully f66-compliant today. Lots of code that
> is f66 compliant is also f77 compliant, at least if one includes Annex
> C (Hollerith) as part of f77. And most f77 (and even f90/f95)
> compilers do implement Hollerith. But some other f66 features are a
> lot harder to find in today's compilers. You might be able to find
> a compiler today that implements the f66 extended range of DO, but
> you'll probably have to search quite a bit.
>
IFC seems to be the only one, AFAICT. But I haven't really searched
much. We can't really afford IFC, and I don't want to have to push
for a license we'll use once.
> Compilers do have bugs. Some have a lot more than others. But if
> your experience leads you to suspect compiler conformance as a first
> suspect, then...well...lets express it in an unbiased manner by saying
> that your experience is a lot different than mine (perhaps because
> your experience might be concentrated in compilers that I tend to avoid;
> been using MS PS 4 a lot?)
>
PS 4?
I tend to stick mainly with GCC because I have better experiences with
it. (And have more flexibility for my other projects.)
> > Which is what perplexed me. The code I was given was labelled as
> > being "Fortran 77 code" but it only compiled in an F95 environment.
>
> Well..it compiled it a particular F95 environment. Apparently that
> particular f95 compiler accepts this particular feature as an extension.
> This has a lot more to do with the particular compiler than with
> whether the compiler conforms to f77, f95, or whatever.
>
It was the IFC trial version.
> > I thought Fortran V was a ratified standard?
>
> No. In fact, I'm not even entirely sure what you would be
> referring to as Fortran V. Some vendors used that terminology, but
> there is no standard known either formally or informally by that name.
> If I recall correctly, CDC might have referred to their Fortran 77
> compiler as Fortran V. If so, that is a vendor's name for a
> particular implementation, not a reference to any standard. Wouldn't
> surprise me if some other vendors (perhaps including Univac, though my
> experience with them is very old and very limitted) also used the
> name, but just saying Fortran V isn't enough to identify it. The
> relevant standard is what is informally known as Fortran 77 (or by its
> various reference numbers such as ANSI X3.9-1978).
Another poster pointed that fact out - the Univac Fortran compiler was
Fortran V. That's all I really knew. I must admit I've learned a
*LOT* from this thread.
Thank you all for your help. You've saved me time and taught me all
the things I needed to know.
-- Charles Banas
Richard Maine
> Richard Maine <nos...@see.signature> wrote in message news:<m3islyt...@altair.dfrc.nasa.gov>...
>> It is really hard to
>> find compilers that are fully f66-compliant today...
>> You might be able to find
>> a compiler today that implements the f66 extended range of DO, but
>> you'll probably have to search quite a bit.
>>
> IFC seems to be the only one, AFAICT.
Really? I know you found that it implements the f66 equivalence,
but does it really also implement the f66 extended range of DO? If
so, I'm impressed (and a bit surprised). I'll have to remember that.
Once in a blue moon the question does come up. (Well, not quite so
often as a blue moon, but anyway it has come up once or twice).
>> been using MS PS 4 a lot?)
> PS 4?
Microsoft PowerStation 4, a notoriously buggy compiler that
Microsoft took off of the market.
Robert Corbett
>
> Really? I know you found that it implements the f66 equivalence,
> but does it really also implement the f66 extended range of DO? If
> so, I'm impressed (and a bit surprised). I'll have to remember that.
> Once in a blue moon the question does come up. (Well, not quite so
> often as a blue moon, but anyway it has come up once or twice).
Sun f95 and I suspect other compilers based on Craysoft f90 still
support extended range DO-loops. The compiler issues a warning
when it sees the GO TO into the body of the DO-loop, but it
compiles the code correctly even at high optimization levels.
The Fortran 95 standard does not require a warning, as the
prohibition against jumping into a block is not a constraint.
I suspect many other compilers also still support extended range
DO-loops. It does not take much effort to support. It is easier
to support extended range DO-loops than it is to explain why they
don't work.
Sincerely,
Bob Corbett
Jan C. Vorbrüggen
Only if you promise to have it scanned and published 8-).
Jan