[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #34 from Paul Thomas  2011-02-20 16:28:09 
UTC ---
I think that we can close this one now.

Thanks to all involved in reporting and fixing.

Fixed on trunk.

Paul

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu.org]

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

--- Comment #33 from Paul Thomas  2011-02-20 16:23:57 
UTC ---
Author: pault
Date: Sun Feb 20 16:23:50 2011
New Revision: 170337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170337
Log:
2011-02-20  Paul Thomas  

PR fortran/45077
PR fortran/44945
* trans-types.c (gfc_get_derived_type): Remove code that looks
for decls in gsym and add call to gfc_get_module_backend_decl.
* trans.h : Add prototype for gfc_get_module_backend_decl.
* trans-decl.c (gfc_get_module_backend_decl): New function.
(gfc_get_symbol_decl): Call it.

2011-02-20  Paul Thomas  

PR fortran/45077
PR fortran/44945
* gfortran.dg/whole_file_28.f90 : New test.
* gfortran.dg/whole_file_29.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_28.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_29.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[paul.richard.thomas at gmail dot com]

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

--- Comment #32 from paul.richard.thomas at gmail dot com  2011-02-19 15:07:03 UTC ---
Dear Tobias,


>
> Aha, you have taken the simple route of modifying trans-decl.c and not the
> whole module reading apparatus :-)

Of course - otherwise, we stand no chance of getting rid of the
regression.  It's only a small addition to the existing section of
code, so I thought that it had the advantage of being very clean too.

The revamp of module.c can wait until we have nothing to do :-)

>
> I think the patch is OK, though I would do some reordering, e.g. "sym->module"
> is not needed as the whole block is enclosed in such a check.
>
> I also would move the block down into
>        if (gsym && gsym->ns && gsym->type == GSYM_MODULE)
> which could be changed into
>        if (!gsym || (gsym && gsym->ns && gsym->type == GSYM_MODULE))
>
> And
> -        gfc_find_symbol (sym->name, gsym->ns, 0, &s);
> +         if (gsym)
> +          gfc_find_symbol (sym->name, gsym->ns, 0, &s);
>
> And then placing the "if (gsym == NULL)" in the
> +       else if (s == NULL)
> block.

All done.

> (In reply to comment #30)
>> The bus error reported in comment #21 has disappeared from my scope between
>> revisions 167584 and 167726;-(
>
> Ditto here, but looking at the dump, I see that the underlying issue is still
> present - and it is fixed by the patch.
>
>  * * *
>
> I will do some more tests.

Let me know when you have done them.  What about a testcase?  I guess
that since it was a testsuite failure we do not need one?
>
> Related to those whole-file DECL issues: I wonder why there are still
> differences between -flto and -fno-lto on Polyhedron (result is correct but
> runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's 
> slink.f
> and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does not
> help).

Is there a PR for Jack's problem.

Thanks for looking at the patch

Paul

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu.org]

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

--- Comment #31 from Tobias Burnus  2011-02-19 
13:08:26 UTC ---
(In reply to comment #29)
> A candidate fix for the PR

Aha, you have taken the simple route of modifying trans-decl.c and not the
whole module reading apparatus :-)

I think the patch is OK, though I would do some reordering, e.g. "sym->module"
is not needed as the whole block is enclosed in such a check.

I also would move the block down into
if (gsym && gsym->ns && gsym->type == GSYM_MODULE)
which could be changed into
if (!gsym || (gsym && gsym->ns && gsym->type == GSYM_MODULE))

And
-gfc_find_symbol (sym->name, gsym->ns, 0, &s);
+ if (gsym)
+  gfc_find_symbol (sym->name, gsym->ns, 0, &s);

And then placing the "if (gsym == NULL)" in the
+   else if (s == NULL)
block.



(In reply to comment #30)
> The bus error reported in comment #21 has disappeared from my scope between
> revisions 167584 and 167726;-(

Ditto here, but looking at the dump, I see that the underlying issue is still
present - and it is fixed by the patch.

 * * *

I will do some more tests.

Related to those whole-file DECL issues: I wonder why there are still
differences between -flto and -fno-lto on Polyhedron (result is correct but
runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's slink.f
and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does not
help).

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[dominiq at lps dot ens.fr]

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

--- Comment #30 from Dominique d'Humieres  
2011-02-19 12:43:04 UTC ---
The bus error reported in comment #21 has disappeared from my scope between
revisions 167584 and 167726;-(

I'll test the patch in comment #29 ASAP.

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |

--- Comment #29 from Paul Thomas  2011-02-19 12:08:49 
UTC ---
Created attachment 23403
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23403
A candidate fix for the PR

I believe that this does the job by generating the missing gsymbol and
populating its namespace with symbols to which backend_decls are attached.

As far as I can see, the same declaration is used consistently for c
(D.1737_69). 

Could somebody please check that I have hold of the right end of the stick?

Thanks

Paul

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[mikael at gcc dot gnu dot org]

--- Comment #28 from mikael at gcc dot gnu dot org  2010-08-18 14:40 ---
(In reply to comment #27)
> This is a very good suggestion. I will have a think about how to implement it
> and will come back to you.  It is consistent with what I had in mind to 
> improve
> the efficiency of module reading.  ie. read_module proceeds as follows:
> 
> (i) On encountering a USE statement, look for the module gsym.  If it does not
> exist, use read_module, as at present, to construct the namespace, without any
> exclusions or renames;
> (ii) In the current scope, create symtrees using the ONLY and the renames and
> point to the symbols in the gsym namespace;
> (iii) Subsequent USEs of the same module proceed by using the gsym namespace.

Hello, 

I have been trying a similar approach before.
One problem you may encounter is that symbols have non-shareable parts. 
For examples symbol attributes such as access or use_rename can differ between
symbols associated to the same entity.  
I tried to split gfc_symbol into an entity-specific part and a symbol-specific
part but that led to huge changes throughout the frontend and to the associated
regressions, so that I eventually gave up. 
A possible way might be to clone the symbol, and keep a pointer to the original
one so that we can get the original backend_decl from it. 

Maybe you will have a different path and won't encounter this problem at all. 
Good luck anyway, that seems the way to go :-)


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2010-08-17 09:42 ---
(In reply to comment #25)
> (In reply to comment #21)
> > In my opinion revision 162487 is only a partial fix of the problem. If I 
> > split
> > a modified test case in two files: [...] I still get [...] Bus error
> 
> (In reply to comment #24)
> > Look at -fdump-tree-original-uid dumps and see if you find the
> > same decl with two different UIDs.  I bet you will.
> 
> One does. The problem is that when the module is not available.
> 
> The variable "c" (of example in comment 21) created for the main program
> "char_array_structure_constructor" but if one searches for the symbol (in
> gfc_get_symbol_decl) via
>   gsym =  gfc_find_gsymbol (gfc_gsym_root, sym->module);
> the result is NULL as the only gsym which exists in gfc_gsym_root is the one
> for "char_array_structure_constructor" as there is none for the module. One
> should create a "fake" gsym for modules, if the module does not exist, and put
> there the variables, functions, and type declarations - such that they can be
> found if needed.
> 

Tobias,

This is a very good suggestion. I will have a think about how to implement it
and will come back to you.  It is consistent with what I had in mind to improve
the efficiency of module reading.  ie. read_module proceeds as follows:

(i) On encountering a USE statement, look for the module gsym.  If it does not
exist, use read_module, as at present, to construct the namespace, without any
exclusions or renames;
(ii) In the current scope, create symtrees using the ONLY and the renames and
point to the symbols in the gsym namespace;
(iii) Subsequent USEs of the same module proceed by using the gsym namespace.

I think that Andy was smoking something or was having a whimsical spell when he
wrote module.c.  Whilst it is very elegant, it is unnecessarily disjunct from
the rest of the frontend and could have been done as above.

Cheers

Paul


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #26 from burnus at gcc dot gnu dot org  2010-07-28 07:41 ---
I expect a similar problem for derived types from modules which are external -
in that case the place to modify would be gfc_get_derived_type -- cf. PR 45077.
Also here, the proper gsym will not be available if the MODULE is only
available via the .mod.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #25 from burnus at gcc dot gnu dot org  2010-07-24 18:14 ---
(In reply to comment #21)
> In my opinion revision 162487 is only a partial fix of the problem. If I split
> a modified test case in two files: [...] I still get [...] Bus error

(In reply to comment #24)
> Look at -fdump-tree-original-uid dumps and see if you find the
> same decl with two different UIDs.  I bet you will.

One does. The problem is that when the module is not available.

The variable "c" (of example in comment 21) created for the main program
"char_array_structure_constructor" but if one searches for the symbol (in
gfc_get_symbol_decl) via
  gsym =  gfc_find_gsymbol (gfc_gsym_root, sym->module);
the result is NULL as the only gsym which exists in gfc_gsym_root is the one
for "char_array_structure_constructor" as there is none for the module. One
should create a "fake" gsym for modules, if the module does not exist, and put
there the variables, functions, and type declarations - such that they can be
found if needed.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[rguenther at suse dot de]

--- Comment #24 from rguenther at suse dot de  2010-07-24 13:43 ---
Subject: Re:  [4.6 Regression] Wrong decl for module vars
 / FAIL: gfortran.dg/char_array_structure_constructor.f90

On Sat, 24 Jul 2010, dominiq at lps dot ens dot fr wrote:

> 
> 
> --- Comment #23 from dominiq at lps dot ens dot fr  2010-07-24 07:49 
> ---
> (In reply to comment #22)
> > > In my opinion revision 162487 is only a partial fix of the problem. If I 
> > > split
> > > a modified test case in two files [...] I still get [...] Bus error
> >
> > Does -flto help?
> 
> Yes:
> 
> [macbook] f90/bug% gfc -flto -fwhole-file -m32 -O3 -fomit-frame-pointer
> char_array_structure_constructor_db_1.f90
> char_array_structure_constructor_db_2.f90
> [macbook] f90/bug% a.out 
> [macbook] f90/bug% 
> 
> > > Note that it is not surprising since -fwhole-file operates at the file 
> > > level.
> >
> > Well, the middle-end also operates on single-file level: Thus, there is no
> > reason to break.
> 
> I am not sure to understand the comment. In my opinion, valid multifile 
> fortran
> should never be miscompiled (and should not require -lto to do so!-).

Look at -fdump-tree-original-uid dumps and see if you find the
same decl with two different UIDs.  I bet you will.

Richard.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[dominiq at lps dot ens dot fr]

--- Comment #23 from dominiq at lps dot ens dot fr  2010-07-24 07:49 ---
(In reply to comment #22)
> > In my opinion revision 162487 is only a partial fix of the problem. If I 
> > split
> > a modified test case in two files [...] I still get [...] Bus error
>
> Does -flto help?

Yes:

[macbook] f90/bug% gfc -flto -fwhole-file -m32 -O3 -fomit-frame-pointer
char_array_structure_constructor_db_1.f90
char_array_structure_constructor_db_2.f90
[macbook] f90/bug% a.out 
[macbook] f90/bug% 

> > Note that it is not surprising since -fwhole-file operates at the file 
> > level.
>
> Well, the middle-end also operates on single-file level: Thus, there is no
> reason to break.

I am not sure to understand the comment. In my opinion, valid multifile fortran
should never be miscompiled (and should not require -lto to do so!-).


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #22 from burnus at gcc dot gnu dot org  2010-07-24 06:52 ---
(In reply to comment #21)
> In my opinion revision 162487 is only a partial fix of the problem. If I split
> a modified test case in two files [...] I still get [...] Bus error

Does -flto help?

> Note that it is not surprising since -fwhole-file operates at the file level.

Well, the middle-end also operates on single-file level: Thus, there is no
reason to break.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2010-07-24 05:38 ---
In my opinion revision 162487 is only a partial fix of the problem. If I split
a modified test case in two files:

[macbook] f90/bug% cat char_array_structure_constructor_db_1.f90
MODULE global
  TYPE :: dt
CHARACTER(4) a
CHARACTER(4) b(2)
  END TYPE
  TYPE (dt), DIMENSION(:), ALLOCATABLE, SAVE :: c
END MODULE global
[macbook] f90/bug% cat char_array_structure_constructor_db_2.f90
program char_array_structure_constructor
  USE global
  call alloc (2)
  if (any (c%a /= "wxyz")) call abort ()
contains
  SUBROUTINE alloc (n)
USE global
ALLOCATE (c(n), STAT=IALLOC_FLAG)
DO i = 1,n
  c (i) = dt ("wxyz",(/"abcd","efgh"/))
ENDDO
  end subroutine alloc
END program char_array_structure_constructor

and compile it with

[macbook] f90/bug% gfc -fwhole-file -m32 -O3 -fomit-frame-pointer
char_array_structure_constructor_db_1.f90
char_array_structure_constructor_db_2.f90

I still get

[macbook] f90/bug% a.out
Bus error

Note that it is not surprising since -fwhole-file operates at the file level.
However if the test is valid fortran, then it should not be miscompiled if
split in two files.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #20 from burnus at gcc dot gnu dot org  2010-07-23 20:15 ---
FIXED on the trunk. Thanks for the report Dominique and thanks Jakub for the
analysis.

I leave the PR open until the patch has been backported to 4.5.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #19 from burnus at gcc dot gnu dot org  2010-07-23 20:13 ---
Subject: Bug 44945

Author: burnus
Date: Fri Jul 23 20:13:07 2010
New Revision: 162487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162487
Log:
2010-07-23  Tobias Burnus  

PR fortran/44945
* trans-decl.c (gfc_get_symbol_decl): Use module decl with
-fwhole-file also for derived types.
* trans-types.c (copy_dt_decls_ifequal): Remove static and
rename to gfc_copy_dt_decls_ifequal.
(gfc_get_derived_type): Update call.
* trans-types.h (gfc_copy_dt_decls_ifequal): Add prototype.

2010-07-23  Tobias Burnus  

PR fortran/44945
* gfortran.dg/char_array_structure_constructor.f90: Add
-fwhole-file as dg-option as it otherwise fails on some
systems.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans-types.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/char_array_structure_constructor.f90


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #18 from burnus at gcc dot gnu dot org  2010-07-16 14:47 ---
Answer: With the patch, one gets:
  gfortran -fwhole-file gfortran.dg/default_initialization_4.f90
without the patch (and still -fwhole-file) it works.

The reason is that one does not "copy" over the backend_decl for the components
- which one might need to do recursively as the components might again be
derived types. Thus, it fails at trans-expr.c's gfc_conv_component_ref for:
gcc_assert (c->backend_decl).

Actually, I do not quite understand why BT_CLASS works - the BT_DERIVED check
of comment 13 should be also false for BT_CLASS, which means its backend_decl
should already be imported with -fwhole-file.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[paul dot richard dot thomas at gmail dot com]

--- Comment #17 from paul dot richard dot thomas at gmail dot com  
2010-07-16 14:38 ---
Subject: Re:  [4.6 Regression] Wrong decl for module vars / 
FAIL: gfortran.dg/char_array_structure_constructor.f90

Dear Tobias,

On Fri, Jul 16, 2010 at 2:08 PM, burnus at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #13 from burnus at gcc dot gnu dot org  2010-07-16 12:08 
> ---
> Patch for -fwhole-file (not regtested).
>
> Paul, do you know why derived types where excluded?

No - maybe because the TYPE_CANONICAL had not been set?

Paul


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-07-16 14:21 ---
(In reply to comment #15)
> I wonder whether the middle-end will not mind different types (the "recycled"
> decl will use backend_decl and its type from wherever it has been generated,
> and the current function will likely have a different type).

I am not sure whether I understand your concern. This is about recycling the
decl of a module variable (sym->attr.flavor == FL_VARIABLE) which should have
the same type everywhere. Thus, from that side there should be no problem.

The only potential issue I see is:

use module
type(t) :: x
x = y  ! where "y" is a module variable of type "t"

where "x" has locally been declared - and thus might have a different type decl
than the module variable. I think one should check this, but I think that does
not make the current patch wrong.

> Plus there is -fno-whole-file (unless we want to make -fwhole-file default and
> remove -fno-whole-file for 4.6).

My idea is to change at some point during 4.6 to using -fwhole-file by default
- though I would not yet remove -fno-whole-file, yet. But the ultimate goal is
to remove -fno-whole-file and add some new flag (-fpermissive) for the few
cases where one wants to disable compilations errors due to fwhole-file
diagnostics.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-07-16 12:32 ---
I wonder whether the middle-end will not mind different types (the "recycled"
decl will use backend_decl and its type from wherever it has been generated,
and the current function will likely have a different type).  Or are backend
types shared for module derived types?  Perhaps conversion between the two
types will be considered useless, still something that needs checking.

Plus there is -fno-whole-file (unless we want to make -fwhole-file default and
remove -fno-whole-file for 4.6).


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-07-16 12:08 ---
(In reply to comment #13)
> Paul, do you know why derived types where excluded?
s/where/were/ - Firefox needs a grammar checker ...


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-07-16 12:08 ---
Patch for -fwhole-file (not regtested).

Paul, do you know why derived types where excluded?

Index: trans-decl.c
===
--- trans-decl.c(revision 162255)
+++ trans-decl.c(working copy)
@@ -1149,11 +1149,9 @@ gfc_get_symbol_decl (gfc_symbol * sym)
 return sym->backend_decl;

   /* If use associated and whole file compilation, use the module
- declaration.  This is only needed for intrinsic types because
- they are substituted for one another during optimization.  */
+ declaration.  */
   if (gfc_option.flag_whole_file
&& sym->attr.flavor == FL_VARIABLE
-   && sym->ts.type != BT_DERIVED
&& sym->attr.use_assoc
&& sym->module)
 {


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-07-16 10:08 ---
As can be seen on:
module mm
contains
  function a ()
integer :: a, b, c
common /blk/ b, c
b = 6
c = 7
a = 8
  end function
end module mm
function b ()
  integer :: b, d, e
  common /blk/ d, e
  b = d + e
end function
program qq
  use mm
  integer :: d, e
  common /blk/ d, e
  interface
function b ()
  integer :: b
end function b
  end interface
  if (a () .ne. 8) call abort
  if (b () .ne. (d + e)) call abort
end
with -fdump-tree-original-all, I believe common decls are fine:
grep blk a.f90.003t.original
  static integer(kind=4)D.8 bD.1555 [value-expr: blk_D.1554.bD.1552];
  static integer(kind=4)D.8 cD.1556 [value-expr: blk_D.1554.cD.1553];
  static integer(kind=4)D.8 dD.1562 [value-expr: blk_D.1554.dD.1560];
  static integer(kind=4)D.8 eD.1563 [value-expr: blk_D.1554.eD.1561];
  static integer(kind=4)D.8 dD.1569 [value-expr: blk_D.1554.dD.1567];
  static integer(kind=4)D.8 eD.1570 [value-expr: blk_D.1554.eD.1568];


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-07-16 09:11 ---
Seemingly, we currently only "recycle" DECLs for procedure decls, but not for
module variable decls.

Looking at
gfortran -fdump-tree-optimized-all -O3 char_array_structure_constructor.f90

one finds (grep MOD_c):
  __global_MOD_cD.1586
  __global_MOD_cD.1606
However, if one removes the second "USE global" and uses the host-associated
variable, it works (i.e. there is only one "__global_MOD_cD").

Expected: The same DECL is used for host associated variables - and, at least
with -fwhole-file, the same DECL is used for the whole file.

I wonder whether the same problem also exists for COMMON symbols.

(Note: While the wrong-code only becomes apparent on x86_64-apple-darwin10, the
bug itself exists on all platforms. Thus, I have emptied the PR's target
field.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-apple-darwin10   |
   GCC host triplet|x86_64-apple-darwin10   |
 GCC target triplet|x86_64-apple-darwin10   |
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-07-16 09:11:44
   date||
Summary|[4.6 Regression] FAIL:  |[4.6 Regression] Wrong decl
   |gfortran.dg/char_array_struc|for module vars / FAIL:
   |ture_constructor.f90|gfortran.dg/char_array_struc
   ||ture_constructor.f90


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