[Bug fortran/51578] New: [4.3/4.4/4.5/4.6/4.7 Regression]

[Bug fortran/51578] New: [4.3/4.4/4.5/4.6/4.7 Regression]

[burnus at gcc dot gnu.org]

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

             Bug #: 51578
           Summary: [4.3/4.4/4.5/4.6/4.7 Regression]
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Reported by Billy Backer at http://gcc.gnu.org/ml/fortran/2011-12/msg00093.html

The program uses (sub2):
  use mod2  ! Imports "mod1" and provides "axx"
  use mod1, oxx=>axx
but using "axx" fails:
  print*,axx
           1
  Error: Symbol 'axx' at (1) has no IMPLICIT type

It works if one reverts the order (sub1).

I could not find anything in the standard which indicates that not both symbols
are imported. I wonder whether it is related to:
  use mod1, oxx=>axx
  use mod1
in that case "axx" is not imported. (Cf. paragraph 7 of Fortran 2008's "11.2.2
The USE statement and use association").

See also http://j3-fortran.org/pipermail/j3/2011-December/004944.html


module mod1
integer :: axx=2
end module mod1

module mod2
use mod1
end module mod2

subroutine sub1
use mod1, oxx=>axx
use mod2
implicit none
print*,axx?? !line compiles OK for gfortran, fails for Intel
end subroutine sub1

subroutine sub2
use mod2
use mod1, oxx=>axx
implicit none
print*,axx??!line fails to compile for gfortran, OK for Intel
end subroutine sub2

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression]

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.3

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-16 14:11:52 UTC ---
The problem is the following in module.c's read_module:

              /* Delete the symtree if the symbol has been added by a USE
                 statement without an ONLY(11.3.2).  Remember that the rsym
                 will be the same as the symbol found in the symtree, for
                 this case.  */
              if (st && (only_flag || info->u.rsym.renamed)
                     && !st->n.sym->attr.use_only
                     && !st->n.sym->attr.use_rename
                     && info->u.rsym.sym == st->n.sym)
                gfc_delete_symtree (&gfc_current_ns->sym_root, name);

The goal is to get it working for:
  use mod1, oxx=>axx
  use mod2
and
  use mod2, oxx=>axx
  use mod1
and with the two lines flipped. But also for combinations such as:
  use mod1
  use mod2, oxx=>axx
  use mod1, only :
  use mod2

But avoid the import of "axx" for:
  use mod2, oxx=>axx
  use mod2
and for having twice "mod1" and for having the line order flipped.


I think one way would be to revamp the import procedure by reading first all
USE lines - consolidating the rename/only information for a module and then
start reading the modules.

(I think host-association of use-associated variables mixed with use statements
should not cause problems, but one should check.

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
            Summary|[4.3/4.4/4.5/4.6/4.7        |[4.3/4.4/4.5/4.6/4.7
                   |Regression]                 |Regression] Import of same
                   |                            |symbol via different
                   |                            |modules and renaming

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-12-17 13:20:47 UTC ---
This pr seems related to (or a duplicate of) pr47168.

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-19 20:45:13 UTC ---
*** Bug 47168 has been marked as a duplicate of this bug. ***

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 13:11:11 UTC ---
Author: burnus
Date: Mon Jan  9 13:11:05 2012
New Revision: 183010

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183010
Log:
2012-01-09  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51578
        * gfortran.h (gfc_use_list):
        * match.h (gfc_use_module): Rename to ...
        (gfc_use_modules): ... this.
        * module.c (use_locus, specified_nonint, specified_int): Remove
        global variable.
        (module_name): Change type to const char*, used with gfc_get_string.
        (module_list): New global variable.
        (free_rename): Free argument not global var.
        (gfc_match_use): Save match to module_list.
        (load_generic_interfaces, read_module): Don't free symtree.
        (write_dt_extensions, gfc_dump_module): Fix module-name I/O due to the
        type change of module_name.
        (write_symbol0, write_generic): Optimize due to the type change.
        (import_iso_c_binding_module, use_iso_fortran_env_module): Use
        locus of rename->where.
        (gfc_use_module): Take module_list as argument.
        (gfc_use_modules): New function.
        (gfc_module_init_2, gfc_module_done_2): Init module_list, rename_list.
        * parse.c (last_was_use_stmt): New global variable.
        (use_modules): New function.
        (decode_specification_statement, decode_statement): Move USE match up
        and call use_modules.
        (next_free, next_fixed): Call use_modules.
        (accept_statement): Don't call gfc_module_use.

2012-01-09  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51578
        * gfortran.dg/use_17.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/use_17.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/match.h
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.6.3                       |4.7.0

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 13:13:34 UTC ---
FIXED on the trunk (GCC 4.7). Too big for backporting [esp. as no one has
reported the bug/regression for years].