public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran
@ 2004-07-13 5:54 billingd at gcc dot gnu dot org
2004-07-13 5:56 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
` (18 more replies)
0 siblings, 19 replies; 20+ messages in thread
From: billingd at gcc dot gnu dot org @ 2004-07-13 5:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
@ 2004-07-13 5:56 ` billingd at gcc dot gnu dot org
2004-07-13 7:09 ` cvs-commit at gcc dot gnu dot org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: billingd at gcc dot gnu dot org @ 2004-07-13 5:56 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
2004-07-13 5:56 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
@ 2004-07-13 7:09 ` cvs-commit at gcc dot gnu dot org
2004-07-13 13:48 ` pinskia at gcc dot gnu dot org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2004-07-13 7:09 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
2004-07-13 5:56 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
2004-07-13 7:09 ` cvs-commit at gcc dot gnu dot org
@ 2004-07-13 13:48 ` pinskia at gcc dot gnu dot org
2004-07-13 20:37 ` toon at moene dot indiv dot nluug dot nl
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-13 13:48 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |rejects-valid
Target Milestone|3.5.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (3 preceding siblings ...)
2004-07-13 20:37 ` toon at moene dot indiv dot nluug dot nl
@ 2004-07-13 20:37 ` Toon Moene
2004-07-14 1:13 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Toon Moene @ 2004-07-13 20:37 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (2 preceding siblings ...)
2004-07-13 13:48 ` pinskia at gcc dot gnu dot org
@ 2004-07-13 20:37 ` toon at moene dot indiv dot nluug dot nl
2004-07-13 20:37 ` [Bug fortran/16511] New: " Toon Moene
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: toon at moene dot indiv dot nluug dot nl @ 2004-07-13 20:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (4 preceding siblings ...)
2004-07-13 20:37 ` [Bug fortran/16511] New: " Toon Moene
@ 2004-07-14 1:13 ` billingd at gcc dot gnu dot org
2004-07-14 3:26 ` billingd at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: billingd at gcc dot gnu dot org @ 2004-07-14 1:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (5 preceding siblings ...)
2004-07-14 1:13 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
@ 2004-07-14 3:26 ` billingd at gcc dot gnu dot org
2004-07-14 12:03 ` tobi at gcc dot gnu dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: billingd at gcc dot gnu dot org @ 2004-07-14 3:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (6 preceding siblings ...)
2004-07-14 3:26 ` billingd at gcc dot gnu dot org
@ 2004-07-14 12:03 ` tobi at gcc dot gnu dot org
2004-07-15 0:32 ` david dot billinghurst at comalco dot riotinto dot com dot au
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tobi at gcc dot gnu dot org @ 2004-07-14 12:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (7 preceding siblings ...)
2004-07-14 12:03 ` tobi at gcc dot gnu dot org
@ 2004-07-15 0:32 ` david dot billinghurst at comalco dot riotinto dot com dot au
2004-07-15 23:22 ` billingd at gcc dot gnu dot org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: david dot billinghurst at comalco dot riotinto dot com dot au @ 2004-07-15 0:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (8 preceding siblings ...)
2004-07-15 0:32 ` david dot billinghurst at comalco dot riotinto dot com dot au
@ 2004-07-15 23:22 ` billingd at gcc dot gnu dot org
2004-12-10 8:56 ` paulthomas2 at wanadoo dot fr
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: billingd at gcc dot gnu dot org @ 2004-07-15 23:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (9 preceding siblings ...)
2004-07-15 23:22 ` billingd at gcc dot gnu dot org
@ 2004-12-10 8:56 ` paulthomas2 at wanadoo dot fr
2005-01-06 14:42 ` tobi at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: paulthomas2 at wanadoo dot fr @ 2004-12-10 8:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (10 preceding siblings ...)
2004-12-10 8:56 ` paulthomas2 at wanadoo dot fr
@ 2005-01-06 14:42 ` tobi at gcc dot gnu dot org
2005-01-06 15:56 ` coudert at clipper dot ens dot fr
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-01-06 14:42 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |19292
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (11 preceding siblings ...)
2005-01-06 14:42 ` tobi at gcc dot gnu dot org
@ 2005-01-06 15:56 ` coudert at clipper dot ens dot fr
2005-01-06 16:11 ` tobi at gcc dot gnu dot org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coudert at clipper dot ens dot fr @ 2005-01-06 15:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (12 preceding siblings ...)
2005-01-06 15:56 ` coudert at clipper dot ens dot fr
@ 2005-01-06 16:11 ` tobi at gcc dot gnu dot org
2005-03-10 14:38 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-01-06 16:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (13 preceding siblings ...)
2005-01-06 16:11 ` tobi at gcc dot gnu dot org
@ 2005-03-10 14:38 ` pinskia at gcc dot gnu dot org
2005-03-10 14:39 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-10 14:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (14 preceding siblings ...)
2005-03-10 14:38 ` pinskia at gcc dot gnu dot org
@ 2005-03-10 14:39 ` pinskia at gcc dot gnu dot org
2005-09-09 0:25 ` cvs-commit at gcc dot gnu dot org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-10 14:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (15 preceding siblings ...)
2005-03-10 14:39 ` pinskia at gcc dot gnu dot org
@ 2005-09-09 0:25 ` cvs-commit at gcc dot gnu dot org
2005-09-09 9:07 ` cvs-commit at gcc dot gnu dot org
2005-09-09 22:15 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-09-09 0:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (16 preceding siblings ...)
2005-09-09 0:25 ` cvs-commit at gcc dot gnu dot org
@ 2005-09-09 9:07 ` cvs-commit at gcc dot gnu dot org
2005-09-09 22:15 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-09-09 9:07 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/16511] Test 19990905-0.f fails with gfortran
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
` (17 preceding siblings ...)
2005-09-09 9:07 ` cvs-commit at gcc dot gnu dot org
@ 2005-09-09 22:15 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-09-09 22:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-09-09 22:15 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-13 5:54 [Bug fortran/16511] New: Test 19990905-0.f fails with gfortran billingd at gcc dot gnu dot org
2004-07-13 5:56 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
2004-07-13 7:09 ` cvs-commit at gcc dot gnu dot org
2004-07-13 13:48 ` pinskia at gcc dot gnu dot org
2004-07-13 20:37 ` toon at moene dot indiv dot nluug dot nl
2004-07-13 20:37 ` [Bug fortran/16511] New: " Toon Moene
2004-07-14 1:13 ` [Bug fortran/16511] " billingd at gcc dot gnu dot org
2004-07-14 3:26 ` billingd at gcc dot gnu dot org
2004-07-14 12:03 ` tobi at gcc dot gnu dot org
2004-07-15 0:32 ` david dot billinghurst at comalco dot riotinto dot com dot au
2004-07-15 23:22 ` billingd at gcc dot gnu dot org
2004-12-10 8:56 ` paulthomas2 at wanadoo dot fr
2005-01-06 14:42 ` tobi at gcc dot gnu dot org
2005-01-06 15:56 ` coudert at clipper dot ens dot fr
2005-01-06 16:11 ` tobi at gcc dot gnu dot org
2005-03-10 14:38 ` pinskia at gcc dot gnu dot org
2005-03-10 14:39 ` pinskia at gcc dot gnu dot org
2005-09-09 0:25 ` cvs-commit at gcc dot gnu dot org
2005-09-09 9:07 ` cvs-commit at gcc dot gnu dot org
2005-09-09 22:15 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).