User account creation filtered due to spam.

Bug 48112 - [4.6/4.7 Regression] generic interface to external function in module
Summary: [4.6/4.7 Regression] generic interface to external function in module
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P4 normal
Target Milestone: 4.6.1
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2011-03-14 13:44 UTC by mhp77
Modified: 2011-04-28 18:48 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-03-15 15:13:27


Attachments
test case (93 bytes, text/x-fortran)
2011-03-14 13:44 UTC, mhp77
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mhp77 2011-03-14 13:44:50 UTC
Created attachment 23650 [details]
test case

Compiling the Fortran module

module module_m
  interface test
     function test1( )  result( test )
       integer ::  test
     end function test1
  end interface test
end module module_m

with gfortran-4.6.0 leads to an internal compiler error. The error occurs because the name of the result variable is equal to the generic name. If the same interface is in a Fortran program no error occurs.

$ gfortran-4.6 -v -c module_m.f90

Using built-in specs.

COLLECT_GCC=gfortran-4.6

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6-20110227-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.6.0 20110227 (experimental) [trunk revision 170543] (Debian 4.6-20110227-1)

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'

/usr/lib/gcc/x86_64-linux-gnu/4.6.0/f951 module_m.f90 -quiet -dumpbase module_m.f90 -mtune=generic -march=x86-64 -auxbase module_m -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.6.0/finclude -o /tmp/ccrmvWWY.s

GNU Fortran (Debian 4.6-20110227-1) version 4.6.0 20110227 (experimental) [trunk revision 170543] (x86_64-linux-gnu)
compiled by GNU C version 4.6.0 20110227 (experimental) [trunk revision 170543], GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

GNU Fortran (Debian 4.6-20110227-1) version 4.6.0 20110227 (experimental) [trunk revision 170543] (x86_64-linux-gnu)
compiled by GNU C version 4.6.0 20110227 (experimental) [trunk revision 170543], GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

module_m.f90:7.19:

end module module_m
                   1
Internal Error at (1):
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
Comment 1 janus 2011-03-15 15:13:27 UTC
Confirmed. Seems to be a regression in 4.6.

At first glance your code looks completely innocent. I think the bug may be somehow related to the interface and the result variable having the same name. Removing (or renaming) the result variable makes the error go away.

In any case the problem seems to occur during module writing. Backtrace:

#0  0x00000000004c9fc8 in error_string (p=0xfbadac84 <Address 0xfbadac84 out of bounds>) at /home/jweil/gcc47/trunk/gcc/fortran/error.c:132
#1  0x00000000004cafd7 in error_print (type=0x11d5508 "", format0=0x11e3a88 "write_symbol(): bad module symbol '%s'", argp=0x7fffffffd980)
    at /home/jweil/gcc47/trunk/gcc/fortran/error.c:671
#2  0x00000000004cbc56 in gfc_internal_error (format=0x11e3a88 "write_symbol(): bad module symbol '%s'") at /home/jweil/gcc47/trunk/gcc/fortran/error.c:977
#3  0x0000000000510351 in write_symbol (n=6, sym=0x1973dd0) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:4848
#4  0x0000000000510572 in write_symbol1 (p=0x1974f60) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:4933
#5  0x00000000005109b2 in write_module () at /home/jweil/gcc47/trunk/gcc/fortran/module.c:5081
#6  0x0000000000510e23 in gfc_dump_module (name=0x7ffff7f651f0 "module_m", dump_flag=1) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:5224
#7  0x000000000051eb09 in gfc_parse_file () at /home/jweil/gcc47/trunk/gcc/fortran/parse.c:4377
#8  0x00000000005641c4 in gfc_be_parse_file () at /home/jweil/gcc47/trunk/gcc/fortran/f95-lang.c:250
#9  0x0000000000a56410 in compile_file () at /home/jweil/gcc47/trunk/gcc/toplev.c:579
#10 0x0000000000a5862b in do_compile () at /home/jweil/gcc47/trunk/gcc/toplev.c:1900
#11 0x0000000000a58778 in toplev_main (argc=2, argv=0x7fffffffddd8) at /home/jweil/gcc47/trunk/gcc/toplev.c:1963
#12 0x00000000005fe2b4 in main (argc=2, argv=0x7fffffffddd8) at /home/jweil/gcc47/trunk/gcc/main.c:36
Comment 2 Jakub Jelinek 2011-03-25 19:52:10 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 3 Tobias Burnus 2011-04-26 09:18:31 UTC
Seems as if the regression has been introduced in by one of the 16 commits between:
  Working: 2010-05-13-r159362
  Failing: 2010-05-18-r159523

Janus, I have the feeling that it is caused either by Rev. 159506 or by Rev. 159476 (PR 44044); both are your commits. I quickly scanned the commits (all 16) but nothing looked suspicious.

I think, one should start a regression hunt to narrow it down to a single commit.
Comment 4 Tobias Burnus 2011-04-26 10:18:23 UTC
Rev. 159475 works, Rev. 159476 fails, which is the following commit:

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159476
Log:
2010-05-17  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/44044
    * resolve.c (resolve_fl_var_and_proc): Move error messages here from ...
    (resolve_fl_variable_derived): ... this place.
    (resolve_symbol): Make sure function symbols (and their result
    variables) are not resolved twice.


The crucial part of the patch is:

+  /* Avoid double resolution of function result symbols.  */
+  if ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
+    return;

 * * *

If one places a break point, one sees first:

(gdb) p sym->name
$5 = 0x2aaaaab40ea8 "test1"
(gdb) p sym->ns->sym_root->name
$8 = 0x2aaaaab40ea8 "test1"
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$10 = 0

and then next:

(gdb) p sym->name
$14 = 0x2aaaaab40ea0 "test"
(gdb) p sym->ns->sym_root->name
$15 = 0x2aaaaab40ea0 "test"
(gdb) p gfc_current_ns->sym_root->name
$16 = 0x2aaaaab40ea8 "test1"
And hence:
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$17 = 1

and finally:

(gdb) p sym->name
$26 = 0x2aaaaab40ea8 "test1"
(gdb) p sym->ns->sym_root->name
$27 = 0x2aaaaab40ea8 "test1"
(gdb) p gfc_current_ns->sym_root->name
$28 = 0x2aaaaab40ea0 "test"
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$25 = 1


Seemingly, the ICE occurs unless both resolutions happen.


(I wonder whether one could use {sym->ns,gfc_current_namespace}->resolved to decide whether one should continue or not; currently, one finds the values "-1" and "0".)
Comment 5 Tobias Burnus 2011-04-26 13:50:53 UTC
(In reply to comment #4)
> The crucial part of the patch is:
> +  /* Avoid double resolution of function result symbols.  */
> +  if ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
> +    return;

If one backs out that part, one gets the diagnostic messages twice for class_20.f03 - which was a general issue, unrelated to BT_CLASS.

 * * *

A variant combining both issues (this PR and class_20.f03) is:

module module_m
  type t
  end type t
  interface test
     function test1( )  result( test )
       import
       class(t) ::  test
     end function test1
  end interface test
end module module_m

For that program, only one error should be printed - and no ICE in module writing ...

 * * *

Draft patch; note that resolve_fl_var_and_proc is *only* about diagnostics:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9888,0 +9889,5 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
+  /* Avoid double diagnostics of function result symbols.  */
+  if ((sym->result || sym->attr.result) && !sym->attr.dummy
+      && (sym->ns != gfc_current_ns))
+    return SUCCESS;
+
@@ -11977,5 +11981,0 @@ resolve_symbol (gfc_symbol *sym)
-  /* Avoid double resolution of function result symbols.  */
-  if ((sym->result || sym->attr.result) && !sym->attr.dummy
-      && (sym->ns != gfc_current_ns))
-    return;
Comment 6 Tobias Burnus 2011-04-28 05:48:23 UTC
Author: burnus
Date: Thu Apr 28 05:48:18 2011
New Revision: 173059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173059
Log:
2011-04-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48112
        * resolve.c (resolve_fl_var_and_proc): Print diagnostic of
        function results only once.
        (resolve_symbol): Always resolve function results.

        PR fortran/48279
        * expr.c (gfc_check_vardef_context): Fix handling of generic
        EXPR_FUNCTION.
        * interface.c (check_interface0): Reject internal functions
        in generic interfaces, unless -std=gnu.

2011-04-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48112
        PR fortran/48279
        * gfortran.dg/interface_35.f90: New.
        * gfortran.dg/erfc_scaled_1.f90: Don't compile with -pedantic.
        * gfortran.dg/func_result_6.f90: Add dg-warning.
        * gfortran.dg/bessel_1.f90: Ditto.
        * gfortran.dg/hypot_1.f90: Ditto.
        * gfortran.dg/proc_ptr_comp_20.f90: Ditto.
        * gfortran.dg/proc_ptr_comp_21.f90: Ditto.
        * gfortran.dg/interface_assignment_4.f90: Ditto.


Added:
    trunk/gcc/testsuite/gfortran.dg/interface_35.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/bessel_1.f90
    trunk/gcc/testsuite/gfortran.dg/erfc_scaled_1.f90
    trunk/gcc/testsuite/gfortran.dg/func_result_6.f90
    trunk/gcc/testsuite/gfortran.dg/hypot_1.f90
    trunk/gcc/testsuite/gfortran.dg/interface_assignment_4.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_21.f90
Comment 7 Tobias Burnus 2011-04-28 18:47:31 UTC
Author: burnus
Date: Thu Apr 28 18:47:28 2011
New Revision: 173127

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173127
Log:
2011-04-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48112
        * resolve.c (resolve_fl_var_and_proc): Print diagnostic of
        function results only once.
        (resolve_symbol): Always resolve function results.

        PR fortran/48279
        * expr.c (gfc_check_vardef_context): Fix handling of generic
        EXPR_FUNCTION.
        * interface.c (check_interface0): Reject internal functions
        in generic interfaces, unless -std=gnu.

2011-04-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48112


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/interface_35.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/expr.c
    branches/gcc-4_6-branch/gcc/fortran/interface.c
    branches/gcc-4_6-branch/gcc/fortran/resolve.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/bessel_1.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/erfc_scaled_1.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/func_result_6.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/hypot_1.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/interface_assignment_4.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_21.f90
Comment 8 Tobias Burnus 2011-04-28 18:48:38 UTC
Fixed on the trunk (4.7) and on the 4.6 branch.

Thanks for the report!