| Summary: | [4.4 Regression] module function name mangled improperly if contained function of same name exists | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Daniel Franke <dfranke> |
| Component: | fortran | Assignee: | Paul Thomas <pault> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | burnus, d, gcc-bugs, tkoenig |
| Priority: | P4 | Keywords: | wrong-code |
| Version: | 4.4.0 | ||
| Target Milestone: | 4.4.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | 4.3.2 | |
| Known to fail: | 4.4.0 | Last reconfirmed: | 2009-01-03 14:15:56 |
| Bug Depends on: | |||
| Bug Blocks: | 32834 | ||
The same holds if G is an external subroutine and the module provides an explicit interface, but not, if the interface is defined in F (errors out).
SUBROUTINE g()
print *, 'external'
END SUBROUTINE
MODULE m
INTERFACE
SUBROUTINE g()
END SUBROUTINE
END INTERFACE
CONTAINS
SUBROUTINE f()
CALL g()
CONTAINS
SUBROUTINE g()
print *, 'contained'
END SUBROUTINE
END SUBROUTINE
END MODULE
use m
call g()
call f()
call g()
end
Works with 4.3: $ gfortran mangle.f90 /tmp/cckeR5NO.o: In function `MAIN__': mangle.f90:(.text+0x2f): undefined reference to `__m_MOD_g' collect2: ld returned 1 exit status $ gfortran-4.3 mangle.f90 $ > Works with 4.3:
Well, not really. gfortran 4.1/4.2/4.3 only call the module procedure, but for "call f()" the contained procedure should be called, which does not work with 4.[1-3].
(In reply to comment #3) > > Works with 4.3: > > Well, not really. gfortran 4.1/4.2/4.3 only call the module procedure, but for > "call f()" the contained procedure should be called, which does not work with > 4.[1-3]. The original test case does work, although it is likely that any real-world program would fail :-) Here's another test case making the problem maybe a bit clearer: $ cat m2.f90 MODULE m CONTAINS SUBROUTINE g(a) END SUBROUTINE SUBROUTINE f() CALL g(i) CONTAINS SUBROUTINE g(i) END SUBROUTINE END SUBROUTINE END MODULE USE m CALL g(a) END $ gfortran m2.f90 m2.f90:15.9: CALL g(a) 1 Error: Type mismatch in argument 'i' at (1); passed REAL(4) to INTEGER(4) I have just posted a patch on the list. Paul Subject: Bug 38594 Author: pault Date: Sat Jan 3 17:47:20 2009 New Revision: 143032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143032 Log: 2009-01-03 Paul Thomas <pault@gcc.gnu.org> PR fortran/38594 * resolve.c (resolve_call): When searching for proper host association, use symtree rather than symbol. For everything except generic subroutines, substitute the symtree in the call rather than the symbol. 2009-01-03 Paul Thomas <pault@gcc.gnu.org> PR fortran/38594 * gfortran.dg/host_assoc_call_3.f90: Make sure that the generic interface still works, in addition to original tests. * gfortran.dg/host_assoc_call_6.f90: New test. Added: trunk/gcc/fortran/ChangeLog-2008 trunk/gcc/testsuite/gfortran.dg/host_assoc_call_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/host_assoc_call_3.f90 Fixed on trunk. Thanks for the report. Paul |
$> cat mangle.f90 MODULE m CONTAINS SUBROUTINE g() END SUBROUTINE SUBROUTINE f() CALL g() CONTAINS SUBROUTINE g() END SUBROUTINE END SUBROUTINE END MODULE USE m CALL g() END $> gfortran-svn mangle.f90 /tmp/ccqzRB3z.o: In function `MAIN__': mangle.f90:(.text+0x2f): undefined reference to `__m_MOD_g' collect2: ld returned 1 exit status $> gfortran-svn --version GNU Fortran (GCC) 4.4.0 20081221 (experimental) The problem disappears if F and G are reordered in the module or the contained G is removed.