From: corbett@lupa.eng.sun.com (Robert Corbett)
Subject: Re: Please test this simple bug
Date: 13 Jan 1996

In article <4d73if$t76@hacgate2.hac.com>, Steve Fry <fry@opticL> wrote:
>There is a persistent bug in many Fortran compilers that began
>creeping in about 10 years ago.  DEC's VAX Fortran worked great,
>then their "f77" had the bug.  WATCOM has the bug, but Lahey's
>F77L EM/32 doesn't; neither does Sun's "f77".  How many others?
>   Before I go to Win95 and one of the 3 compilers
>people are talking about, could someone using each of these
>verify that the bug has been eliminated (preferably squashed and
>ground into the floor for good).
>
>    1 FORMAT(1X,G9.3)
>      WRITE(6,1)-.9999
>
>A compiler with the bug will print out 5 or 9 asterisks instead
>of the correct answer (-1.00)

The reason for the "persistent bug" is an interaction between the
requirements of the FORTRAN 77 standard and the desire to produce
rounded results.  Section 13.5.9.2.3 of ANSI X3.9-1978 gives
the rules for the G edit descriptor.  Those rules do not take
rounding into account.  When the value to be printed is just less
than a power of 10 and the number of digits in the d portion of
the edit descriptor is small, the resulting decimal value does not
fit in the field.  If it doesn't fit, you must asterisk it (see
Section 13.5.9 (5) of ANSI X3.9-1978).

DEC and Watcom are sticking more strictly to the letter of the
standard than Sun.  At Sun, we choose to believe that X3J3 couldn't
mean what they wrote.  We shall continue to handle G edit descriptors
this way unless and until

    (1)  X3J3 issues an interpretation saying that they really
	 did intend to require stupid results,

    (2)  the FSTC adds a test requiring stupid results to the
	 FCVS, or

    (3)  a customer buying $100,000,000+ of Sun equipment asks
	 for this really quite clever feature.

Fortran 90 has a similar, but different, problem with the G edit
descriptor.  The Fortran 90 rules assume that values between
between half a decimal ulp less than a power of 10 and that power
of ten always round up.  That is true for IEEE round-to-nearest,
but it is not true for any of the other IEEE rounding modes.

					Sincerely,
					Robert Corbett

From: corbett@lupa.Eng.Sun.COM (Robert Corbett)
Subject: Re: How to express support of __FUNC__?
Date: 20 Jul 1995

In article <3ubiel$11l0@tornews.torolab.ibm.com>,
Dave Mooney <dmm@vnet.ibm.com> wrote:
>
>Alternatively, you could convince your compiler vendors to support it
>as an extension.  The more prior art a feature has, the more likely the
>Committee will be to accept it into the Standard.

In 25+ years of following the work of the ANSI programming language
committees, I have found the opposite to be the case.  The ANSI Fortran
committee went out of its way to avoid adopting industry accepted
extensions, such as INTEGER*2 and STRUCTURE.  As a result, to be
commercially viable compilers must recognize both the industry-accepted
extensions and the standard's extensions that provide the same
functionality.

The ANSI C committee seems to be going down the same road.  For example,
every C compiler I have used recently implements a "long long" data type.
The ANSI C committee seems set on adopting another solution to the
problem.

					Sincerely,
					Bob Corbett

From: corbett@lupa.Sun.COM (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: tab edit descriptors and nonadvancing I/O
Date: 19 Jun 2000 18:41:40 GMT

In article <8il3m8$evus@harrier.le.ac.uk>,
Clive Page  <cgp@nospam.le.ac.uk> wrote:
>In article <ueg0qgnhrw.fsf@altair.dfrc.nasa.gov>,
>Richard Maine  <maine@altair.dfrc.nasa.gov> wrote:
>>
>>Probably part of the text from the infamous interpretation 125. :-(
>>
>
>I hope we are not getting into the waters entered by  Algol68, in which it
>was said that the correct interpretation depended on being able to
>distinguish, when reading the Standard,  between a roman and an italic
>comma.

Don't worry.  The text of the standard that describes
nonadvancing I/O is so unclear that commas make no
difference, much less the fonts of commas.

					Sincerely,
					Bob Corbett

From: corbett@lupa.Sun.COM (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: tab edit descriptors and nonadvancing I/O
Date: 21 Jun 2000 01:51:17 GMT

In article <y4pupc24ed.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,
Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
>corbett@lupa.Sun.COM (Robert Corbett) writes:
>
>> Don't worry.  The text of the standard that describes
>> nonadvancing I/O is so unclear that commas make no
>> difference, much less the fonts of commas.
>
>Given how formatted I/O works in Fortran, shouldn't it have been specified
>as a finite-state machine or something similar?
>
>	Jan

Nonadvancing I/O is I/O that is distributed over multiple statements.
The Fortran standard defines the effects of each statement in isolation.
It does not do a good job of describing interactions across multiple
statements.

A simple example of a problem is the definition of "current record."
The standard states

      If a file is positioned within a record, that record
      is the current record; otherwise, there is no current
      record.

Consider the code

      OPEN (10, FILE='XXX', ACCESS='SEQUENTIAL', FORM='FORMATTED',      &
     &      POSITION='REWIND')
      READ (10, '()', ADVANCE='NO')

After the OPEN statement, the file is positioned at its initial point.
There is no current record.

The situation is less clear after the READ statement.  Fortran allows
empty records.  If the first record in the file is an empty record,
is it possible for the file to be positioned "within" the record?
Of course the answer must be yes, but it is hard to justify that answer
based on the text of the standard and the usual meanings of words.

The standard could have provided precise definitions of what it meant
by "file position" and "current records," but such definitions would
have added a couple of pages to the standard.

					Sincerely,
					Bob Corbett

From: corbett@lupa.eng.sun.com (Robert Corbett)
Subject: Re: Fortran 95 superset of Fortran 90?
Date: 28 Jan 1997

In article <32E9AFA8.17A0@cris.com>, James Giles  <JGiles@cris.com> wrote:
>
>The standard does not specify the accuracy of *any* arithmetic
>operation.  Indeed, the semantics of *all* calculations are
>implementation dependent - even those calculations involving only
>integers.
>
>What the standard *does* say is that the trip count of a loop:
>
>   Do index = exp1, exp2, exp3
>
>will be MAX (INT((exp2-exp1+exp3)/exp3),0).

While I know James Giles understands, those who are innocent of
interpreting standards might think that the expression for the trip
count conveys information.  Some years ago, I wrote to the Fortran
standard committee asking if an implementation must implement
floating-point DO-loops using the trip count expression given in the
standard.  I was told that the loop must be implemented as if the
expression were used, but that the standard placed no restriction on
the accuracy with which the trip count expression is evaluated.  In
particular, I was told that a processor is allowed to implement a
floating-point DO-loop in a manner that causes the loop to execute
an unbounded number of times, even when the mathematically exact
value of the trip count expression is a small integer.  At the time,
I was surprised.

					Sincerely,
					Bob Corbett

From: robert.corbett@sun.com (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Which compiler (long)
Date: 9 Sep 2004 16:56:16 -0700
Message-ID: <cb977dbc.0409091556.7de6ee41@posting.google.com>

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<lfP%c.270759$8_6.92794@attbi_s04>...

> I wonder what fraction of the existing Fortran statements are
> part of programs written to each standard.  Count each program
> as to the oldest standard it satisfies, weighted by the number
> of statements in the program.
>
> My first guess is 25% each, F66, F77, F90, F95, but
> I wouldn't be surprised if the older ones were higher, though.
>
> There are some very large programs written to older standards
> that haven't changed much and likely the changes that were made
> kept to the original standard.
>
> So, my second guess is 35%, 25%, 20%, 20%.

It's hard to say.  I estimate that at least 10% of the Fortran
statements I see in user programs are not standard according to
any official standard including MIL-STD 1753 and Industrial
Real-Time Fortran.

                                           Sincerely,
                                           Bob Corbett

From: robert.corbett@sun.com (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Which compiler (long)
Date: 10 Sep 2004 21:56:37 -0700
Message-ID: <cb977dbc.0409102056.12eed1f2@posting.google.com>

Richard Maine <nospam@see.signature> wrote in message news:<87acvzhre4.fsf@vega.site>...

> Oh.  I just thought of another way for it to be plausible to me.
> I bet an awful lot of those 10% are declarations with
> type*n syntax.  Yep, that could be a lot of statements.

You would win that bet if you could find anyone willing to take it.

> Now 10% of the programs....that would be very different.  I'd
> suspect numbers upwards of 90% there.

I'd say more like 99.44%.  However, regardless of the use of features
that do not conform to official standards, the programs are often
remarkably portable.

Many well-known libraries, such as the BLAS, use nonstandard features.
A Fortran compiler vendor whose product cannot handle those libraries
will not have many customers.

                                              Sincerely,
                                              Bob Corbett

From: robert.corbett@sun.com (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Which compiler (long)
Date: 10 Sep 2004 22:12:50 -0700
Message-ID: <cb977dbc.0409102112.13377846@posting.google.com>

Richard Maine <nospam@see.signature> wrote in message news:<87acvzhre4.fsf@vega.site>...
..
>
> 10% of the statements?  Wow!  That's pretty incredible...

If you count statements that contain tabs as nonstandard,
the percentage is much greater than that.

                                        Sincerely,
                                        Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Detect EOF for direct access, unformatted files?
Date: 23 Apr 2005 20:23:43 -0700
Message-ID: <1114313023.312040.227000@f14g2000cwb.googlegroups.com>

> Is there a way to detect "end of file" for direct access, unformatted
> files? The Fortran standard requires IOSTAT < 0 be returned only for
> sequential files that read an EOF record.

The Fortran standard does not provide a way to detect end-of-file
for a direct-access file.  The standard does not apply the concept
end-of-file to direct-access files.  The Fortran standard does not
allow a standard conforming program to try to read a record that
does not exist.  If a program does try to read a record that does
not exist, the standard no longer has anything to say about the
behavior of the program, and so, a conforming implementation is
free to report an end-of-file condition (or do anything else).

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: fortran standard
Date: Fri, 5 Dec 2008 02:40:26 -0800 (PST)
Message-ID: <e04fa6d1-4c4c-4bcb-acb3-f0d29c90f27f@w24g2000prd.googlegroups.com>

On Dec 5, 1:46 am, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> George wrote:
>
> > Somewhere along the line, I lost the latest pdf of the fortran standard
> > available for poor people.
>
> http://www.j3-fortran.org/doc/year/04/04-007.pdf
>
> Is the one I have.  Maybe there is a later one now.

That is the last draft of the Fortran 2003 standard.  Nothing
available for free download is likely to be closer to the
official Fortran 2003 standard.  There are Fortran 2008
drafts.

Bob Corbett

From: Charles Russell <NOSPAM@bellsouth.net>
Newsgroups: comp.lang.fortran
Subject: Re: Error in decimal places?
Message-ID: <v%Ryh.397$I8.46@bignews8.bellsouth.net>
Date: Thu, 08 Feb 2007 21:37:27 -0600

Steven G. Kargl wrote:
> In article <1170957424.611637.240030@v33g2000cwv.googlegroups.com>,
> 	a.e.pace@gmail.com writes:
>
>>      program test
>>      implicit double precision (a-h,o-z)
>>      dimension  A(2)
>>      A(1)=0.8
>>      A(2)=0.0
>
>
> 0.8 and 0.0 are default real literal constants.  Try 0.8D0 and 0.0D0.
>

  The programmer has declared his intent that these variables should be
double precision.  An intelligent input routine would recognize this, so
that the programmer would not have to type D0 after every floating point
number.

  Most of the counterintuitive features of fortran, which are
fortunately few, will be with us forever since changes would break old
code, and the wealth of old code is one of the glories of the language.
But would it do much harm to change this particular feature? Using too
much precision can rarely hurt.

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Error in decimal places?
Date: 8 Feb 2007 21:56:44 -0800
Message-ID: <1171000604.332981.318580@v45g2000cwv.googlegroups.com>

On Feb 8, 7:37 pm, Charles Russell <NOS...@bellsouth.net> wrote:

>   Most of the counterintuitive features of fortran, which are
> fortunately few, will be with us forever since changes would break old
> code, and the wealth of old code is one of the glories of the language.
> But would it do much harm to change this particular feature? Using too
> much precision can rarely hurt.

Many FORTRAN 77 compilers evaluated floating-point
constant expressions to the highest precision available
and only chopped them back to a lower precision when
necessary.  For example, in the case of the assignment
of a single-precision constant to a floating-point, a
compiler might evaluate the constant to quadruple
precision, and then convert it back to double precision
before doing the assignment.

The members of X3J3 in the late 1970's to early 1980's
were inclined to allow compilers to maintain a bit of
extra precision for the convenience of programmers.
The members of X3J3, now just J3, from the mid 1980's
until today were not and are not.

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Array size by module variables
Date: 2 Mar 2007 02:15:56 -0800
Message-ID: <1172830556.219064.130780@n33g2000cwc.googlegroups.com>

On Mar 1, 12:21 pm, Rich Townsend <r...@barVOIDtol.udel.edu> wrote:
> Johan wrote:
> > Hello,
>
> > The code below cause a Segmentation fault using the intel fortran
> > compiler version 9.1.039 at Linux. It runs ok using the g95 and gfortran
> > compilers.
>
> > Is there something not correct in the code which can cause the
> > segmentation fault?
>
> > Thanks,
>
> > Johan
>
> > module general
> > integer, parameter :: dp = kind(0d0)
> > integer :: ntmax
> > end module
>
> > program tst
> > use general
> > implicit none
> > ntmax = 2001
> > call frequencyRecon
> > end
>
> > subroutine frequencyRecon
> > use general
> > implicit none
> > integer, parameter :: total_f=55
> > integer, parameter :: ndof=12
> > real(dp) :: forcett(ndof,ntmax,total_f)
> > write(*,*) 'freq rec'
> > end subroutine
>
> This works fine with version 9.1.040, and also with the Lahey lf95 v6.2. It
> looks like a compiler bug.
>
> It's disappointing that the Intel compiler has been around for some time now,
> and yet shows no sign of asymptoting toward being (ostensibly) bug free. I'm
> forever having to implement workarounds, especially with array-based stuff; and
> in many cases, the bug cannot obviously be reproduced by anything smaller than a
> ~50,000 line code, which I'm hesitant to send to Intel in a bug report.

Fortran 95 is a big language, and Fortran 95 compilers,
especially optimizing Fortran 95 compilers, tend to be
big programs.  Fortran 2003 is much worse, which is why
there are no compilers for it yet.  Fortran 2008 looks
as if it will be as big relative to Fortran 2003 as
Fortran 2003 is to Fortran 95.

Big programs tend to have bugs.

I have considered designing a new small dialect of Fortran
for writing numerical applications, but I am too busy fixing
bugs to make much progress on it.  I think a small Fortran-like
language would be good for numerical applications.

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Equivalence of derived types with default initializers?
Date: 23 Mar 2007 15:24:39 -0700
Message-ID: <1174688679.048163.25660@y80g2000hsf.googlegroups.com>

On Mar 23, 2:36 am, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
wrote:
> robert.corb...@sun.com wrote:
> > On Mar 16, 4:15 pm, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
> > wrote:
> >> Does anyone else have thoughts on this?  Joost is good enough with this
> >> sort of thing that I'm suspecting he's probably right and I'm probably
> >> wrong, but I'd like to have independent confirmation one way or the other.
>
> > You've missed the implication that a variable can become
> > both defined and undefined at the same time.
>
> > Consider the program
>
> >       PROGRAM MAIN
> >         TYPE T1
> >           SEQUENCE
> >           INTEGER I
> >         END TYPE
> >         TYPE T2
> >           SEQUENCE
> >           INTEGER I
> >         END TYPE
> >         INTEGER I
> >         TYPE(T1) R1
> >         TYPE(T2) R2
> >         EQUIVALENCE(I, R1, R2)
> >         I = 5
> >         PRINT *, I, R1, R2
> >         END
>
> > Section 14.6.3.2 of the Fortran 95 standard makes it clear that
> > the storage sequence of I and the storage sequences of the
> > components of R1 and R2 are storage associated.  Section 14.6.3.3
> > assures that I, R1, and R2 are totally associated.  Section 14.7.5,
> > item (10) assures that the assignment to I causes the components of
> > R1 and R2 to become defined.  Section 14.7.1 assures that when the
> > components of R1 and R2 become defined, the objects R1 and R2
> > become defined.  Section 14.7.6, item (1) assures that when R1
> > becomes defined R2 becomes undefined and when R2 becomes defined
> > R1 becomes undefined.
>
> Ok, now I am quite thoroughly confused.
>
> However, I have a sneaking suspicion that that simply means that I have
> correctly understood what you're saying!

Yes, if you are confused, you have correctly understood what the
standard says.  It is clear that what the standard says is not what
the authors intended it to say, but it is not clear they did intend
it to say.

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: rpc's comments on Fortran 2008, part 1
Date: Thu, 10 Jul 2008 19:41:06 -0700 (PDT)
Message-ID: <14d1a89e-a606-472e-9018-8d8d6c9e3782@34g2000hsf.googlegroups.com>

Title:    Coarrays should be optional

The Fortran 2008 draft should not be approved unless coarrays
are made optional.

Coarrays are too new to belong in Fortran 2008.  Many models
for parallel programming have been developed.  Coarrays are
not clearly superior to these other models.  Making coarrays
optional would allow further development of coarrays without
creating problems if other models of parallel programming
prove more successful.


Title:    Restore the restrictions on internal procedures
          as targets and actual arguments.

The Fortran 2008 draft should not be approved unless the
prohibition on using internal procedures as pointer targets
and actual arguments are restored.

The Fortran 2008 draft allows internal procedures to be
pointer targets and dummy arguments.  The only practical
implementation of the functionality as specified in the
current draft requires the use of self-modifying code.
Self-modifying code has long been established to be a
security problem.  Some secure operating systems, such as
SELinux and Trusted Debian, can be built in ways that do
not allow self-modifying code.  Recent versions of Mac OS
require users to mark executables that allow self-modifying
code.

The functionality could be provided in ways that do not
require self-modifying code.  Traditionally, pointers to
internal procedures have been implemented as two parts:
the address of the entry point of the internal procedure
and the context in which the procedure is to be executed.
In modern languages, such pointers are called "closures."
Adding a way to declare closures would permit the
functionality of pointers to internal procedures without
putting security at risk.

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: rpc's comments on Fortran 2008, part 2
Date: Thu, 10 Jul 2008 21:00:06 -0700 (PDT)
Message-ID: <5855a235-7be7-4e83-abe5-776eda965b32@x35g2000hsb.googlegroups.com>

Title:    the official interpretations should be examined

The Fortran standard should be written in such a manner that
a reader who is not a member of the committee should be able
to understand it without needing to read the interpretations
issued against Fortran 90, Fortran 95, and Fortran 2003.

The committee should examine the interpretations issued
against the previous Fortran standards to see that those
interpretations are reflected in the text of the new standard.
Many of those interpretations were requested by senior members
of the committee, a succession of interpretations were
considered and rejected before the final interpretation was
issued, and yet the text of the standard was left unchanged.
Given that the unmodified text raised questions in the minds
of members of the committee, that text can reasonably be
supposed to be confusing to readers who are not members of
the committee.


Title:    generic resolution

Consider the program

      PROGRAM MAIN
        INTERFACE COS
          REAL FUNCTION MYCOS(X)
          END FUNCTION
        END INTERFACE
        CALL SUBR
      CONTAINS
        SUBROUTINE SUBR
          INTRINSIC COS
          PRINT *, COS(0.0)
        END SUBROUTINE
      END

      REAL FUNCTION MYCOS(X)
        MYCOS = 2.0
      END

When compiled using the compilers provided by Sun,
Cray, Intel, HP, and PathScale, the program prints
2.0.  When compiled using the compilers provided by
IBM, NAG, and GCC, the program prints 1.0.
Interpretations 90/000082 and 90/000086 require the
latter interpretation.  Text should be added to the
standard itself clarifying this point.


Title:    File position and the left tab limit

I filed request for interpretartion 95/000027.  The
interpretation issued by the committee is clear, but
it is not reflected in the text of the standard.  The
standard does not clearly state that the character
position within the current record is part of the
file position.  Questions regarding the character
position have been asked about Fortran 90, Fortran 95,
and Fortran 2003.

Paragraph 3 of Section 9.3.4.1 should state that if
a record file is positioned within a record, the
character position within the record is part of the
file position.

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: rpc's comments on Fortran 2008, part 3
Date: Fri, 11 Jul 2008 22:25:14 -0700 (PDT)
Message-ID: <bef4d085-ed52-463e-817f-f0f93db677cf@m73g2000hsh.googlegroups.com>

Title:    Fix error in type equivalence

Paragraph 2 of Section 4.5.1.3 states

    Data entities in different scoping units also
    have the same type if they are declared with
    reference to different derived-type definitions
    that specify the same type name, ...

Why should it matter that that the data entities
are in different scoping units?  Shouldn't the
same rules apply if the data entities are in the
same scoping unit?  The answer to the first
question is that it should not matter, and the
answer to the second is that the same rules
should apply.

Examination of the first paragraph of Section
4.5.3.1 reveals what likely happened.  That
paragraph states

    Derived-type definitions with the same name
    may appear in different scoping units, in
    which case they may be independent and
    describe different derived types or they may
    describe the same type.

Obviously, the phrase "in different scoping units"
in the quotation from paragraph 2 was misapplied
to the data entity.  It should have been applied to
the derived-types definitions.


Title:    derived-type equivalence

The idea of describing derived type equivalence in
terms of data entities, as is done in Section 4.5.1.3
of the Fortran 2008 draft is screwy.  Type equivalence
should be described in terms of the types and the
derived-type definitions that define them.

Title:    equivalence of circular types

The draft Fortran standard allow circular type
definitions (see Section 4.5.3).  Type
equivalence for derived types that do not have
the SEQUENCE property or the BIND attribute is
trivial, they are equivalent only if they are
defined by the same derived-type definition.
For type that have the SEQUENCE property or
the BIND attribute, type equivalence is
defined in terms of a hybrid of structural
equivalence and name equivalence.  This hybrid
condition is easier to test than pure
structural equivalence, but harder to test than
pure name equivalence.  Like other definitions
of type equivalence based on structural
equivalence, the definition of the equivalence
of two circular types is tricky.  The draft
Fortran standard avoids this problem by not
defining what it means for two circular types
to be equivalent.

Consider the program

      MODULE MOD
        TYPE T1
          SEQUENCE
          INTEGER I
          TYPE(T2), POINTER :: P
        END TYPE
        TYPE T2
          SEQUENCE
          INTEGER I
          TYPE(T1), POINTER :: P
        END TYPE
      END

      PROGRAM MAIN
        USE MOD, ONLY: T3 => T1, T4 => T2
        TYPE T1
          SEQUENCE
          INTEGER I
          TYPE(T2), POINTER :: P
        END TYPE
        TYPE T2
          SEQUENCE
          INTEGER I
          TYPE(T1), POINTER :: P
        END TYPE

        TYPE(T1) :: X
        TYPE(T3) :: Y

        Y%I = 1
        NULLIFY(Y%P)
        X = Y
      END

The types T1 and T2 defined in the module might or
might not be equivalent to the types T1 and T2 defined
in the main program depending on the definition of type
equivalence for types with circular definitions.
Because the standard does not provide such a definition,
implementors have had to supply their own definitions.
I have found three distinct definitions implemented by
different compilers.

In the case of the example given above, Sun Fortran
considers the types T1 and T2 defined in the module to be
equivalent to the types T1 and T2 defined in the main
program.  A compiler from another vendor considers them
to be different and produces the error message

fortcom: Error: testa.f, line 32: An assignment of
         different structure types is invalid.   [Y]
        X = Y
.............^
compilation aborted for testa.f (code 1)

when it tries to compile the code above.

I know two ways to precisely define structural equivalence
of circular types.  One is to give an algorithm for testing
type equivalence.  The other is to define type equivalence
in terms of equivalence classes.  Either approach will be
considerably long and more complicated than the definition
of derived-type equivalence given in the draft standard.

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: rpc's comments on Fortran 2008, part 3
Date: Mon, 14 Jul 2008 20:01:28 -0700 (PDT)
Message-ID: <34d2efdd-e0dd-4457-9657-0512c9726df5@j22g2000hsf.googlegroups.com>

On Jul 13, 8:53 pm, Ron Ford <r...@nowhere.net> wrote:
> On Fri, 11 Jul 2008 22:25:14 -0700 (PDT), robert.corb...@sun.com posted:
>
> <snip>
>
> > Examination of the first paragraph of Section
> > 4.5.3.1 reveals what likely happened.  That
> > paragraph states
>
> >     Derived-type definitions with the same name
> >     may appear in different scoping units, in
> >     which case they may be independent and
> >     describe different derived types or they may
> >     describe the same type.
>
> > Obviously, the phrase "in different scoping units"
> > in the quotation from paragraph 2 was misapplied
> > to the data entity.  It should have been applied to
> > the derived-types definitions.
>
> When did this language enter the standard?

It has been present since the Fortran 90 standard.  I pointed
out the problem to the committee years ago, but nothing was
done about it.  Many of the issues I pointed out in my public
review comments for Fortran 2008 are present in earlier
versions of the standard.

Bob Corbett