User account creation filtered due to spam.

Bug 16511 - Test 19990905-0.f fails with gfortran
Summary: Test 19990905-0.f fails with gfortran
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.2
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks: 19292 20405
  Show dependency treegraph
 
Reported: 2004-07-13 05:54 UTC by David Billinghurst
Modified: 2005-09-09 22:15 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-06-28 01:19:09


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Billinghurst 2004-07-13 05:54:38 UTC
g77 test 19990905-0.f fails with gfortran.

The test is 

c { dg-do compile }
* =foo0.f in Burley's g77 test suite.
      subroutine sub(a)
      common /info/ iarray(1000)
      equivalence (m,iarray(100)), (n,iarray(200))
      real a(m,n)
      a(1,1) = a(2,2)
      end

In file /usr/local/src/gcc/gcc/testsuite/gfortran.dg/g77/19990905-0.f:6

      real a(m,n)
            1
Error: Variable 'm' cannot appear in the expression at (1)

According to Steve Kargl:

Ftnchek says its legal Fortran 77.

kargl[209] ftnchek -f77=all 19990905-0.f

FTNCHEK Version 3.2 November 2002

File 19990905-0.f:
 0 syntax errors detected in file 19990905-0.f
No main program found
Warning: Common block INFO Elements used but never set: all

Whoops, in looking at the gfortran error message, I thought I
sent a PR for this, because I have this noted in private testsuite
as a failure.
Comment 1 CVS Commits 2004-07-13 07:08:48 UTC
Subject: Bug 16511

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	billingd@gcc.gnu.org	2004-07-13 07:08:24

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg/g77: 19990905-0.f 20010519-1.f 
	                               20030115-1.f 20030326-1.f 
	                               970125-0.f 980519-2.f 990115-1.f 
	                               alpha1.f xformat.f 

Log message:
	2004-07-13  David Billinghurst (David.Billinghurst@riotinto.com)
	
	Copy files from g77.f-torture/compile.
	Add "{ dg-do compile}".  Other changes as noted
	* gfortran.dg/g77/19990905-0.f: XFAIL PR 16511
	* gfortran.dg/g77/20010519-1.f: Add dg-warning as required
	* gfortran.dg/g77/20030115-1.f: Add dg-warning as required
	* gfortran.dg/g77/20030326-1.f: XFAIL PR 16511
	* gfortran.dg/g77/970125-0.f: Add dg-excess-errors.
	* gfortran.dg/g77/980519-2.f: Declare hd_S,hd_Z,hd_T
	* gfortran.dg/g77/990115-1.f: Declare RANK as INTEGER
	* gfortran.dg/g77/alpha1.f: Separate declaration and DATA
	statement to conform to standard.  Append alpha1.x for reference.
	* gfortran.dg/g77/xformat.f: Add dg-warning

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3993&r2=1.3994
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/19990905-0.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/20010519-1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/20030115-1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/20030326-1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/970125-0.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/980519-2.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/990115-1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/alpha1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/xformat.f.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 2 Toon Moene 2004-07-13 20:37:11 UTC
Subject: Re:  New: Test 19990905-0.f fails with gfortran

billingd at gcc dot gnu dot org wrote:
> g77 test 19990905-0.f fails with gfortran.
> 
> The test is 
> 
> c { dg-do compile }
> * =foo0.f in Burley's g77 test suite.
>       subroutine sub(a)
>       common /info/ iarray(1000)
>       equivalence (m,iarray(100)), (n,iarray(200))
>       real a(m,n)
>       a(1,1) = a(2,2)
>       end
> 
> In file /usr/local/src/gcc/gcc/testsuite/gfortran.dg/g77/19990905-0.f:6
> 
>       real a(m,n)
>             1
> Error: Variable 'm' cannot appear in the expression at (1)
> 
> According to Steve Kargl:
> 
> Ftnchek says its legal Fortran 77.

That can't be true, because it isn't - my take on it is that ftnchek 
simply doesn't recognise the issues.

m is equivalenced to an item in common.  That makes `real a(m,n)' a 
declaration of an automatic array, which is a Fortran 90 beast (it 
didn't exist in Fortran 77)

However, to me it looks like a valid (though complicated) way to define 
such a thing.

Hope this helps,

Comment 3 David Billinghurst 2004-07-14 01:13:06 UTC
I will disagree with Toon, here.  I think is is conforming Fortran 77,
since the array a() is a subroutine argument.

I may read through the standard.
Comment 4 David Billinghurst 2004-07-14 03:26:32 UTC
Change of opinion here.  

This is not standard Fortran 77, and I don't think it is standard 
Fortran 95.  My opinion is that gfortran is correct to reject this.

From ANSI X3.9 Section 5.5.1:

An adjustable array declarator must be a dummy array declarator. At 
least one dummy argument list of the subprogram must contain the name 
of the adjustable array. A variable name that appears in a dimension 
bound expression of an array must also appear as a name either in 
every dummy argument list that contains the array name or in a common
block in that subprogram.

Fortran 95 talks about "explicit-shape arrays" that are dummy arguments
in Section 5.1.2.4.1.  The array bounds must be specification-expr, as
given in Section 7.1.6.2.  This is quite a list, but I don't think
we can define values using EQUIVALENCE.
Comment 5 Tobias Schlüter 2004-07-14 12:02:59 UTC
I disagree, I think this is valid code. We reject it, because we don't resolve
equivalences in any meaningful way.

The expression in the upper or lower bound of an array specification must be a
specification expression. Informally, a specification expression is an
expression that can be evaluated at procedure entry, which is the case here.

In legalese terms:
By R734 a specification expression is a scalar int expression, which is a
restricted expression. A variable is a restricted expression if it is a
"variable that is in a common block or a variable that is a subobject of such a
variable". This is the case here. I couldn't find a quote that this property is
inherited via equivalences, but I would assume that this is the intended meaning.
Comment 6 david.billinghurst@comalco.riotinto.com.au 2004-07-15 00:32:06 UTC
Subject: RE:  Test 19990905-0.f fails with gfortran

tobi at gcc dot gnu dot org wrote:
> ------- Additional Comments From tobi at gcc dot gnu dot org 
> 2004-07-14 12:02 ------- I disagree, I think this is valid code. We
> reject it, because we don't resolve equivalences in any meaningful
> way. 
> 

I won't argue.  My only reason in looking at standards is to 
distinguish between bugs and extensions. 
Comment 7 David Billinghurst 2004-07-15 23:22:41 UTC
After following the discussion on c.l.f (thanks Steve) it seems the
code in question "clearly" (?) conforms to F90 standard.

Richard Maine wrote:
Date: 14 Jul 2004 08:16:06 -0700

Klaus Wacker <wacker@physik.uni-dortmund.de> writes: 

> I think it could have already been legal in Fortran 77. As the array 
> is passed in as an argument, no dynamic memory allocation is 
> necessary. However, the standard says: 
> 
> | A variable name that appears in a dimension bound expression of an 
> | array must also appear as a name either in every dummy argument list 
> | that contains the array name or in a common block in that subprogram. 
> 
> The phrase "as a name" seems to exclude the association to a common 
> via equivalence. 

I find that phrase a little strange in general. After all, a name 
isn't in a common block. A name is in a common statement, but not 
a common block. I'd be tempted to interpret that as the variable 
being in the common block. But I guess I don't find it definitive. 

The f90 standard is a little more clear here. The corresponding 
requirement for a specification expression is 

  "A variable that is in a common block or a variable that is the subobject 
   of a variable in a common block." 

No funniness about names being in common blocks. I'd say that the 
equivalenced variable is probably alsso "in" the common block, 
though the precise definition of common blocks is tricky indeed 
(I'm occasionally amazed at the people who mention how simple 
common is - I think they mostly don't understand its real definition, 
but only how simple it can be if you restrict yourself to simple 
use of it...which isn't a bad idea). Hmm... Ah. I'm slighly surprised, 
but I do manage to find the words to cover this pretty much in exactly 
the form needed. F90 5.5.2.1(2) 

  "Data objects associated with an entity in a common block are considered 
   to be in that common block." 

So I think I'll go with "clearly" legal in f90, but subject to debate 
in f77. Since you aren't going to get a formal f77 interp any more, 
that's probably how it will have to stand
Comment 8 Paul Thomas 2004-12-10 08:56:27 UTC
(In reply to comment #7)

The COMMON block has nothing to do with the problem:

subroutine sub(a)
  integer :: m=2,n=2
  real a(m,n)
end subroutine sub

Fails to compile too, with the same message.
Comment 9 Francois-Xavier Coudert 2005-01-06 15:56:51 UTC
The reduced case given in comment #9 fails to compile with Intel compiler ("This
entity cannot be in a specification expression"), Sun ("Local variable "M" must
be a dummy argument or in common to be used in a bounds specification
expression") and NEC ("Variable "m" in specification expression is invalid"). It
compiles with Portland and MIPSpro compilers.

However, the inital (comment #0) snippet compiles fine on all compilers
mentionned above. So I guess the common block as something to do with it.
Comment 10 Tobias Schlüter 2005-01-06 16:11:44 UTC
(In reply to comment #9)
> However, the inital (comment #0) snippet compiles fine on all compilers
> mentionned above. So I guess the common block as something to do with it.

Indeed, the common block makes this code legal, the code in #9 is rightfully
rejected by gfortran.

Comment 11 Andrew Pinski 2005-03-10 14:38:18 UTC
This is an equivalenced problem so linking to 20405
Comment 12 Andrew Pinski 2005-03-10 14:39:44 UTC
The way I came to that conclusion was the following code worked:
c { dg-do compile }
      subroutine sub(a)
      common /info/ m, n
      real a(m,n)
      a(1,1) = a(2,2)
      end
Comment 13 CVS Commits 2005-09-09 00:24:17 UTC
Subject: Bug 16511

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pault@gcc.gnu.org	2005-09-09 00:23:18

Modified files:
	gcc/fortran    : gfortran.h match.c module.c primary.c 
	                 trans-common.c trans-decl.c ChangeLog 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: module_blank_common.f90 
	                           module_double_reuse.f90 
	                           common_equivalence_1.f 
	                           common_equivalence_2.f 
	                           common_equivalence_3.f 
	                           contained_equivalence_1.f90 
	                           module_commons_1.f90 
	                           module_equivalence_1.f90 
	                           nested_modules_1.f90 

Log message:
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/18878
	* module.c (find_use_name_n): Based on original
	find_use_name. Either counts number of use names for a
	given real name or returns use name n.
	(find_use_name, number_use_names): Interfaces to the
	function find_use_name_n.
	(read_module): Add the logic and calls to these functions,
	so that mutiple reuses of the same real name are loaded.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/22304
	PR fortran/23270
	PR fortran/18870
	PR fortran/16511
	PR fortran/17917
	* gfortran.h: Move definition of BLANK_COMMON_NAME from trans-
	common.c so that it is accessible to module.c. Add common_head
	field to gfc_symbol structure. Add field for the equivalence
	name AND new attr field, in_equivalence.
	* match.c (gfc_match_common, gfc_match_equivalence): In loops
	that flag common block equivalences, emit an error if the
	common blocks are different, using sym->common_head as the
	common block identifier. Ensure that symbols that are equivalence
	associated with a common block are marked as being in_common.
	* module.c (write_blank_common): New.
	(write_common): Use unmangled common block name.
	(load_equiv): New function ported from g95.
	(read_module): Call load_equiv.
	(write_equiv): New function ported from g95. Correct
	string referencing for gfc functions. Give module
	equivalences a unique name.
	(write_module): Call write_equiv and write_blank_common.
	* primary.c (match_variable) Old gfc_match_variable, made
	static and third argument provided to indicate if parent
	namespace to be visited or not.
	(gfc_match_variable) New. Interface to match_variable.
	(gfc_match_equiv_variable) New. Interface to match_variable.
	* trans-common.c (finish_equivalences): Provide the call
	to create_common with a gfc_common_header so that
	module equivalences are made external, rather than local.
	(find_equivalences): Ensure that all members in common block
	equivalences are marked as used. This prevents the subsequent
	call to this function from making local unions.
	* trans-decl.c (gfc_generate_function_code): Move the call to
	gfc_generate_contained_functions to after the call to
	gfc_trans_common so the use-associated, contained common
	blocks produce the correct references.
	(gfc_create_module_variable): Return for equivalenced symbols
	with existing backend declaration.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/18878
	* gfortran.dg/module_double_reuse.f90: New.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/23270
	PR fortran/22304
	PR fortran/18870
	PR fortran/17917
	PR fortran/16511
	* gfortran.dg/common_equivalence_1.f: New.
	* gfortran.dg/common_equivalence_2.f: New.
	* gfortran.dg/common_equivalence_3.f: New.
	* gfortran.dg/contained_equivalence_1.f90: New.
	* gfortran.dg/module_blank_common.f90: New.
	* gfortran.dg/module_commons_1.f90: New.
	* gfortran.dg/module_equivalence_1.f90: New.
	* gfortran.dg/nested_modules_1.f90: New.
	* gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange
	equivalences and add comment to connect the test with
	the PR.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.84&r2=1.85
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.44&r2=1.45
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcc&r1=1.30&r2=1.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.67&r2=1.68
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.543&r2=1.544
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_blank_common.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_double_reuse.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_2.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_3.f.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/contained_equivalence_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_commons_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_equivalence_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6033&r2=1.6034

Comment 14 CVS Commits 2005-09-09 09:06:37 UTC
Subject: Bug 16511

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	pault@gcc.gnu.org	2005-09-09 09:06:09

Modified files:
	gcc/fortran    : gfortran.h match.h match.c module.c primary.c 
	                 trans-common.c trans-decl.c ChangeLog 
	gcc/testsuite/gfortran.dg/g77: 19990905-0.f 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: module_blank_common.f90 
	                           module_double_reuse.f90 
	                           common_equivalence_1.f 
	                           common_equivalence_2.f 
	                           common_equivalence_3.f 
	                           contained_equivalence_1.f90 
	                           module_commons_1.f90 
	                           module_equivalence_1.f90 
	                           nested_modules_1.f90 

Log message:
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/18878
	* module.c (find_use_name_n): Based on original
	find_use_name. Either counts number of use names for a
	given real name or returns use name n.
	(find_use_name, number_use_names): Interfaces to the
	function find_use_name_n.
	(read_module): Add the logic and calls to these functions,
	so that mutiple reuses of the same real name are loaded.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/22304
	PR fortran/23270
	PR fortran/18870
	PR fortran/16511
	PR fortran/17917
	* gfortran.h: Move definition of BLANK_COMMON_NAME from trans-
	common.c so that it is accessible to module.c. Add common_head
	field to gfc_symbol structure. Add field for the equivalence
	name AND new attr field, in_equivalence.
	* match.c (gfc_match_common, gfc_match_equivalence): In loops
	that flag common block equivalences, emit an error if the
	common blocks are different, using sym->common_head as the
	common block identifier. Ensure that symbols that are equivalence
	associated with a common block are marked as being in_common.
	* module.c (write_blank_common): New.
	(write_common): Use unmangled common block name.
	(load_equiv): New function ported from g95.
	(read_module): Call load_equiv.
	(write_equiv): New function ported from g95. Correct
	string referencing for gfc functions. Give module
	equivalences a unique name.
	(write_module): Call write_equiv and write_blank_common.
	* primary.c (match_variable) Old gfc_match_variable, made
	static and third argument provided to indicate if parent
	namespace to be visited or not.
	(gfc_match_variable): New. Interface to match_variable.
	(gfc_match_equiv_variable): New. Interface to match_variable.
	* trans-common.c (finish_equivalences): Provide the call
	to create_common with a gfc_common_header so that
	module equivalences are made external, rather than local.
	(find_equivalences): Ensure that all members in common block
	equivalences are marked as used. This prevents the subsequent
	call to this function from making local unions.
	* trans-decl.c (gfc_generate_function_code): Move the call to
	gfc_generate_contained_functions to after the call to
	gfc_trans_common so the use-associated, contained common
	blocks produce the correct references.
	(gfc_create_module_variable): Return for equivalenced symbols
	with existing backend declaration.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/18878
	* gfortran.dg/module_double_reuse.f90: New.
	
	2005-09-09  Paul Thomas  <pault@gcc.gnu.org>
	
	PR fortran/23270
	PR fortran/22304
	PR fortran/18870
	PR fortran/17917
	PR fortran/16511
	* gfortran.dg/common_equivalence_1.f: New.
	* gfortran.dg/common_equivalence_2.f: New.
	* gfortran.dg/common_equivalence_3.f: New.
	* gfortran.dg/contained_equivalence_1.f90: New.
	* gfortran.dg/module_blank_common.f90: New.
	* gfortran.dg/module_commons_1.f90: New.
	* gfortran.dg/module_equivalence_1.f90: New.
	* gfortran.dg/nested_modules_1.f90: New.
	* gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange
	equivalences and add comment to connect the test with
	the PR.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.8.11&r2=1.31.8.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.2.2&r2=1.31.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.22.2.10&r2=1.22.2.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.4&r2=1.23.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.2.5&r2=1.54.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.114&r2=1.335.2.115
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_blank_common.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_double_reuse.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_1.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_2.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_equivalence_3.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/contained_equivalence_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_commons_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/module_equivalence_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/19990905-0.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=1.1.48.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.394&r2=1.5084.2.395

Comment 15 Andrew Pinski 2005-09-09 22:15:09 UTC
Fixed.