[Bug fortran/16511] New: Test 19990905-0.f fails with gfortran

[Bug fortran/16511] New: Test 19990905-0.f fails with gfortran

[billingd at gcc dot gnu dot org]

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.

-- 
           Summary: Test 19990905-0.f fails with gfortran
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: billingd at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[billingd at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-07-13 05:56:06
               date|                            |
   Target Milestone|---                         |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-13 07:08 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
   Target Milestone|3.5.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

Re: [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran

[Toon Moene]

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,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[toon at moene dot indiv dot nluug dot nl]

------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2004-07-13 20:37 -------
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,



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2004-07-14 01:13 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2004-07-13 05:56:06         |2004-07-14 01:13:07
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2004-07-14 03:26 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[tobi at gcc dot gnu dot org]

------- 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.

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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[david dot billinghurst at comalco dot riotinto dot com dot au]

------- Additional Comments From david dot billinghurst at comalco dot riotinto dot com dot au  2004-07-15 00:32 -------
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. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[billingd at gcc dot gnu dot org]

------- Additional Comments From billingd at gcc dot gnu dot org  2004-07-15 23:22 -------
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


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2004-07-14 01:13:07         |2004-07-15 23:22:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 08:56 -------
(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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[tobi at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |19292
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[coudert at clipper dot ens dot fr]

------- Additional Comments From coudert at clipper dot ens dot fr  2005-01-06 15:56 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |coudert at clipper dot ens
                   |                            |dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-01-06 16:11 -------
(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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-10 14:38 -------
This is an equivalenced problem so linking to 20405

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-10 14:39 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-09 00:24 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-09 09:06 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511

[Bug fortran/16511] Test 19990905-0.f fails with gfortran

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-09 22:15 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511