* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
@ 2005-07-05 5:33 ` pinskia at gcc dot gnu dot org
2005-07-06 5:09 ` albertm at uphs dot upenn dot edu
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-07-05 5:33 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
Keywords| |wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
2005-07-05 5:33 ` [Bug fortran/22304] " pinskia at gcc dot gnu dot org
@ 2005-07-06 5:09 ` albertm at uphs dot upenn dot edu
2005-07-06 11:32 ` tkoenig at gcc dot gnu dot org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: albertm at uphs dot upenn dot edu @ 2005-07-06 5:09 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From albertm at uphs dot upenn dot edu 2005-07-06 05:09 -------
Created an attachment (id=9212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9212&action=view)
minimal test case
The bug persists in gcc version 4.1.0 20050702 (experimental)
If I replace:
EQUIVALENCE(K(1),I),(J,K(2))
with
EQUIVALENCE(I,K(1)),(J,K(2))
or
EQUIVALENCE(K(1),I),(K(2),J)
the code does not demonstrate this problem.
Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
2005-07-05 5:33 ` [Bug fortran/22304] " pinskia at gcc dot gnu dot org
2005-07-06 5:09 ` albertm at uphs dot upenn dot edu
@ 2005-07-06 11:32 ` tkoenig at gcc dot gnu dot org
2005-07-06 16:59 ` albertm at uphs dot upenn dot edu
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2005-07-06 11:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From tkoenig at gcc dot gnu dot org 2005-07-06 11:32 -------
In this case, we forget the common block name.
>From the .t02.original:
MAIN__ ()
{
static union
{
int4 o[300000];
} equiv.0;
equiv.0.o[8] = 1;
mysub ();
}
mysub ()
{
static union
{
int4 o[300000];
} equiv.1;
The strange thing is that this goes away when the last equivalence
is deleted:
MAIN__ ()
{
ibm.o[8] = 1;
mysub ();
mysub ()
{
...
What I find also very strange is the missing closing brace in MAIN__.
This may point towards memory corruption somewhere.
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050702/configure --prefix=/home/zfkts --enable-
languages=c,f95
Thread model: posix
gcc version 4.1.0 20050702 (experimental)
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu dot
| |org
OtherBugsDependingO| |19292, 20405
nThis| |
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Known to fail| |4.1.0
Last reconfirmed|0000-00-00 00:00:00 |2005-07-06 11:32:02
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (2 preceding siblings ...)
2005-07-06 11:32 ` tkoenig at gcc dot gnu dot org
@ 2005-07-06 16:59 ` albertm at uphs dot upenn dot edu
2005-07-06 17:26 ` albertm at uphs dot upenn dot edu
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: albertm at uphs dot upenn dot edu @ 2005-07-06 16:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From albertm at uphs dot upenn dot edu 2005-07-06 16:59 -------
(In reply to comment #2)
First, thank you for taking an interest in this issue.
Secondly, if I may speculate, it seems to me that there is a problem
in how gfc_equiv structures are marked as "used" in trans-common.c
As an expriment, if in gfc_trans_common I commented-out finish_equivalences,
then the example "bug.f" (see attachment above) produces the expected
output. This is clearly not a solution, but might be a hint at the problem.
Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (3 preceding siblings ...)
2005-07-06 16:59 ` albertm at uphs dot upenn dot edu
@ 2005-07-06 17:26 ` albertm at uphs dot upenn dot edu
2005-08-03 7:06 ` paulthomas2 at wanadoo dot fr
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: albertm at uphs dot upenn dot edu @ 2005-07-06 17:26 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From albertm at uphs dot upenn dot edu 2005-07-06 17:26 -------
(In reply to comment #3)
One more bit of speculation. I still think there is an issue with
marking "->used" in gfc_equiv structures. The following change will
make the test case "work", but since I only vaguely understand the
intention of the code, I wouldn't recommoned its use:
*** trans-common.c 2005-07-06 13:17:28.029531913 -0400
--- trans-common.c.orig 2005-07-05 21:09:38.882901773 -0400
***************
*** 695,701 ****
{
add_condition (n, eq, other);
eq->used = 1;
- other->used = 1; /*FIXME or HELPME, this is mostly a guess*/
found = TRUE;
/* If this symbol is the first in the chain we may find other
matches. Otherwise we can skip to the next equivalence. */
--- 695,700 ----
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (4 preceding siblings ...)
2005-07-06 17:26 ` albertm at uphs dot upenn dot edu
@ 2005-08-03 7:06 ` paulthomas2 at wanadoo dot fr
2005-08-03 15:02 ` albertm at uphs dot upenn dot edu
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: paulthomas2 at wanadoo dot fr @ 2005-08-03 7:06 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From paulthomas2 at wanadoo dot fr 2005-08-03 07:06 -------
Mike,
As I promised on the fortran list, I am about to tackle module equivalences.
Since there are clearly associated issues with equivalences in general, I need
to come to grips with those too.
Your contributions to the investigation are very welcome and most helpful. Did
you go any further with this?
Paul Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (5 preceding siblings ...)
2005-08-03 7:06 ` paulthomas2 at wanadoo dot fr
@ 2005-08-03 15:02 ` albertm at uphs dot upenn dot edu
2005-08-05 5:47 ` pault at gcc dot gnu dot org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: albertm at uphs dot upenn dot edu @ 2005-08-03 15:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From albertm at uphs dot upenn dot edu 2005-08-03 15:02 -------
Subject: Re: gfortran silently changes values in equilvane
nce'd variables
Greetings!
On Wed, 3 Aug 2005, paulthomas2 at wanadoo dot fr wrote:
> ------- Additional Comments From paulthomas2 at wanadoo dot fr
> 2005-08-03 07:06 -------
> Mike,
>
> As I promised on the fortran list, I am about to tackle module
> equivalences.
I really appreciate the work folks like you do.
> Your contributions to the investigation are very welcome and most
> helpful. Did
> you go any further with this?
Thank you, but no, I got as far as the messages which I posted, then
decided that I really didn't know what I was doing and stopped.
I should explain that my immediate purpose was a program
called "EGSnrc" and there seem to be other issues with
regards to compiling this under gfortran, so I've gone back
to g77.
I am a little busy, but I might be able to try some more.
However, I have no real experience programming compilers,
and I don't think I understand the
intended logic of the algorithms in the code which
I tweaked. Is there something I should have read
that would give me a clue?
Again, thanks.
Sincerely,
Mike Albert
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (6 preceding siblings ...)
2005-08-03 15:02 ` albertm at uphs dot upenn dot edu
@ 2005-08-05 5:47 ` pault at gcc dot gnu dot org
2005-08-05 6:08 ` pault at gcc dot gnu dot org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-08-05 5:47 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 05:47 -------
> I am a little busy, but I might be able to try some more.
> However, I have no real experience programming compilers,
> and I don't think I understand the
Join the club!
> intended logic of the algorithms in the code which
> I tweaked. Is there something I should have read
> that would give me a clue?
Unfortunately, no. I think that it is gong to take me a week or two to come to
grips with how this should work. There are many other problems with
modules/equivalences/common, which need to be sorted out together.
Thank you again for your help.
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (7 preceding siblings ...)
2005-08-05 5:47 ` pault at gcc dot gnu dot org
@ 2005-08-05 6:08 ` pault at gcc dot gnu dot org
2005-09-09 0:24 ` cvs-commit at gcc dot gnu dot org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pault at gcc dot gnu dot org @ 2005-08-05 6:08 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 06:08 -------
This is amusing.....
integer o(4), b, c
COMMON /IBM/ o
EQUIVALENCE (o(1),b),(C,o(4))
o(3)=1
CALL MYSUB1
CALL MYSUB2
END
subroutine MYSUB1
integer o (4), b, c
COMMON /IBM/ o
EQUIVALENCE (o(1), b), (o(4), c)
WRITE (6,*) "IN MYSUB1: o(3)= ", o(3)
RETURN
END
subroutine MYSUB2
integer o (4), b, c
COMMON /IBM/ o
EQUIVALENCE (o(1), b), (c, o(4))
WRITE (6,*) "IN MYSUB2: o(3)= ", o(3)
RETURN
END
IN MYSUB1: o(3)= 0
IN MYSUB2: o(3)= 134519416
The code shows that SUB1 references the common block, whereas SUB2 goes for a
home grown equivalence. This is a good clue as to where things are failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (8 preceding siblings ...)
2005-08-05 6:08 ` pault at gcc dot gnu dot org
@ 2005-09-09 0:24 ` 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:17 ` pinskia at gcc dot gnu dot org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-09-09 0:24 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 00:24 -------
Subject: Bug 22304
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=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (9 preceding siblings ...)
2005-09-09 0:24 ` 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:17 ` pinskia at gcc dot gnu dot org
11 siblings, 0 replies; 13+ 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 22304
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=22304
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
2005-07-05 5:07 [Bug fortran/22304] New: gfortran silently changes values in equilvanence'd variables albertm at uphs dot upenn dot edu
` (10 preceding siblings ...)
2005-09-09 9:07 ` cvs-commit at gcc dot gnu dot org
@ 2005-09-09 22:17 ` pinskia at gcc dot gnu dot org
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-09-09 22:17 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=22304
^ permalink raw reply [flat|nested] 13+ messages in thread