[Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64

[Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64

[adrian at llnl dot gov]

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

             Bug #: 51522
           Summary: ICE in gfortran 4.6.2, x86_64
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: adrian@llnl.gov


Created attachment 26066
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26066
this one is only reproducible when the modules are spread over multiple files

I accidentally created this ICE while I was delta-debugging Bug 51520; my
script was only testing for *any* Segmentation fault instead of a specific one
;-)

The machine is running Ubuntu 10.04, 64 bit on an Intel Xeon.

  gfortran -I. -O0  -c -o sidl.o sidl.f03 && \
  gfortran -O0  -c -o vect_Utils_type.o vect_Utils_type.f03 && \
  debugx f951 gfortran -O0  -c -o vectortest.o vectortest.f03 

GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/prantl1/sw/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/f951...done.
(gdb) r
Starting program:
/home/prantl1/sw/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/f951 vectortest.f03
-quiet -dumpbase vectortest.f03 -mtune=generic -march=x86-64 -auxbase-strip
vectortest.o -O0 -fintrinsic-modules-path
/home/prantl1/sw/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/finclude -o
/tmp/ccEoT7Es.s
vectortest.f03:13.10:

  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
          1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
vectortest.f03:15.7:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
       1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
vectortest.f03:10.49-47:

  integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
                                               2 1
Warning: Implicitly declared variable 'u' at (1) may not be C interoperable but
it is a dummy argument to the BIND(C) procedure 'vect_utils_vuisunit_c' at (2)
vectortest.f03:10.54-47:

  integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
                                               2      1
Warning: Implicitly declared variable 'tol' at (1) may not be C interoperable
but it is a dummy argument to the BIND(C) procedure 'vect_utils_vuisunit_c' at
(2)
vectortest.f03:10.65-47:

  integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
                                               2                 1
Warning: Implicitly declared variable 'exception' at (1) may not be C
interoperable but it is a dummy argument to the BIND(C) procedure
'vect_utils_vuisunit_c' at (2)
vectortest.f03:4.49-47:

  integer(c_int) function vect_Utils_vuIsZero_c(u, tol, exception) bind(c)
                                               2 1
Warning: Implicitly declared variable 'u' at (1) may not be C interoperable but
it is a dummy argument to the BIND(C) procedure 'vect_utils_vuiszero_c' at (2)
vectortest.f03:4.54-47:

  integer(c_int) function vect_Utils_vuIsZero_c(u, tol, exception) bind(c)
                                               2      1
Warning: Implicitly declared variable 'tol' at (1) may not be C interoperable
but it is a dummy argument to the BIND(C) procedure 'vect_utils_vuiszero_c' at
(2)
vectortest.f03:4.65-47:

  integer(c_int) function vect_Utils_vuIsZero_c(u, tol, exception) bind(c)
                                               2                 1
Warning: Implicitly declared variable 'exception' at (1) may not be C
interoperable but it is a dummy argument to the BIND(C) procedure
'vect_utils_vuiszero_c' at (2)
vectortest.f03:15.47-2:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
  2                                            1
Warning: Implicitly declared variable 'u' at (1) may not be C interoperable but
it is a dummy argument to the BIND(C) procedure 'vect_utils_vunorm_c' at (2)
vectortest.f03:15.52-2:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
  2                                                 1
Warning: Implicitly declared variable 'tol' at (1) may not be C interoperable
but it is a dummy argument to the BIND(C) procedure 'vect_utils_vunorm_c' at
(2)
vectortest.f03:15.62-2:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
  2                                                           1
Warning: Implicitly declared variable 'badlevel' at (1) may not be C
interoperable but it is a dummy argument to the BIND(C) procedure
'vect_utils_vunorm_c' at (2)
vectortest.f03:15.73:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
                                                                         1
vectortest.f03:15.2:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
  2
Warning: Implicitly declared variable 'exception' at (1) may not be C
interoperable but it is a dummy argument to the BIND(C) procedure
'vect_utils_vunorm_c' at (2)
vectortest.f03:15.2:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
  1
Warning: Variable 'vect_utils_vunorm_c' at (1) may not be a C interoperable
kind but it is bind(c)

Program received signal SIGSEGV, Segmentation fault.
resolve_symbol (sym=0x13037a0) at ../../gcc-4.6.1/gcc/fortran/resolve.c:12390
12390          sym->formal_ns->refs++;

(gdb) bt
#0  resolve_symbol (sym=0x13037a0)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:12390
#1  0x000000000052bd27 in traverse_ns (st=<value optimized out>, 
    func=0x50dec0 <resolve_symbol>)
    at ../../gcc-4.6.1/gcc/fortran/symbol.c:3333
#2  0x0000000000518cd4 in resolve_types (ns=0x1302da0)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:13520
#3  0x000000000050d774 in gfc_resolve (ns=0x1302da0)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:13619
#4  gfc_resolve (ns=0x1302da0) at ../../gcc-4.6.1/gcc/fortran/resolve.c:13607
#5  0x000000000050ed55 in resolve_symbol (sym=0x1303b30)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:12378
#6  0x000000000052bd27 in traverse_ns (st=<value optimized out>, 
    func=0x50dec0 <resolve_symbol>)
    at ../../gcc-4.6.1/gcc/fortran/symbol.c:3333
#7  0x0000000000518cd4 in resolve_types (ns=0x129c4c0)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:13520
#8  0x000000000050d774 in gfc_resolve (ns=0x129c4c0)
    at ../../gcc-4.6.1/gcc/fortran/resolve.c:13619
#9  gfc_resolve (ns=0x129c4c0) at ../../gcc-4.6.1/gcc/fortran/resolve.c:13607
#10 0x0000000000502f19 in gfc_parse_file ()
    at ../../gcc-4.6.1/gcc/fortran/parse.c:4403
#11 0x000000000053bf36 in gfc_be_parse_file ()
---Type <return> to continue, or q <return> to quit---
    at ../../gcc-4.6.1/gcc/fortran/f95-lang.c:250
#12 0x000000000079a11c in compile_file (argc=14, argv=0x7fffffffdfa8)
    at ../../gcc-4.6.1/gcc/toplev.c:579
#13 do_compile (argc=14, argv=0x7fffffffdfa8)
    at ../../gcc-4.6.1/gcc/toplev.c:1900
#14 toplev_main (argc=14, argv=0x7fffffffdfa8)
    at ../../gcc-4.6.1/gcc/toplev.c:1963
#15 0x00007ffff7409c4d in __libc_start_main (main=<value optimized out>, 
    argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=0x7fffffffdf98)
    at libc-start.c:226
#16 0x000000000049cd05 in _start ()
(gdb)

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-12
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-12-12 23:21:37 UTC ---
I get the segmentation fault from 4.5.3 up to today trunk on both the multiple
files and with all of them concatenate in a single one.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 13:28:47 UTC ---
With the patch for PR 51578 (for GCC 4.7), the ICE is fixed. For the lines


integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception) &
use, intrinsic :: iso_c_binding
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
end function vect_Utils_vuNorm_c


one get the errors


   integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)&
           1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression


   real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind
        1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression


I think the second one is perfect - there is no "USE ISO_C_Binding" statement
in "function vect_Utils_vuNorm_c".


The first error is not that good as the problem is the "&" in
   function foo() &
     use m

A better error message would be a syntax error, pointing at the "&" - but I
think it is not really needed and also not easy to give a helpful message.

Hence, I close this PR as FIXED. If you think something else should be
improved, feel free to reopen this bug.


Thanks Adrian for reporting the internal compiler error.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-09 13:38:38 UTC ---
With the following change

--- pr51522.f90    2011-12-13 00:17:20.000000000 +0100
+++ pr51522_db.f90    2012-01-09 12:15:44.000000000 +0100
@@ -265,9 +266,11 @@ interface
   integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
     use, intrinsic :: iso_c_binding
   end function vect_Utils_vuIsUnit_c
-  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
+  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)    
     use, intrinsic :: iso_c_binding
+  end function vect_Utils_vuTriIneqHolds_c
   real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
+    use, intrinsic :: iso_c_binding
   end function vect_Utils_vuNorm_c
 end interface
 end module vect_Utils_F03

the code compiles (with a lot of warnings), but complains at link time:

Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
  "_vect_Utils_getEPV", referenced from:
      ___vect_utils_type_f03_MOD_cache_epv_s in ccxe8Zdc.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jb at gcc dot gnu.org
         Resolution|FIXED                       |

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-31 15:52:19 UTC ---
Revision 183681 

Author:    jb
Date:    Sun Jan 29 20:29:50 2012 UTC (43 hours, 17 minutes ago)
Changed paths:    2
Log Message:    
Reduce size of pointer_info tree, minor cleanups.

2012-01-29  Janne Blomqvist  <jb@gcc.gnu.org>

    * module.c (pointer_info): Make true_name and module pointers
    rather than arrays, order pointers before other fields.
    (free_pi_tree): free true_name and module as well.
    (mio_read_string): Rename to read_string.
    (mio_write_string): Remove.
    (load_commons): Use read_string.
    (read_module): Use read_string rather than mio_internal_string.
    (write_blank_common): Call write_atom directly.
    (write_symbol): Likewise.

gives again an ICE for the test case and the reduced one below. Since I see in
comment #2:

> With the patch for PR 51578 (for GCC 4.7), the ICE is fixed. For the lines ...

I cannot decide if the bug has been really fixed or only hidden, so I reopen
the PR.

Revision 183680 does not give any ICE

[macbook] f90/bug% /opt/gcc/gcc4.7p-183680/bin/gfortran  -w pr51522_red.f90
pr51522_red.f90:94.10:

  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
          1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
pr51522_red.f90:96.7:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
       1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression

while r183681 does

[macbook] f90/bug% /opt/gcc/gcc4.7p-183681/bin/gfortran -w pr51522_red.f90
pr51522_red.f90:94.10:

  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
          1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
pr51522_red.f90:96.7:

  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
       1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This is how much I can reduce the original test. Commenting any line in the
first two derived types make the ICE to go away (I lost patience after that;-).
Also trying to avoid the ton of warnings by defining the arguments in the last
interface block makes the ICE to go away.

module vect_Utils_type_F03
  use, intrinsic :: iso_c_binding
  type, bind(c) :: vect_Utils_sepv_t
    type(c_funptr) :: f__set_hooks_static
    type(c_funptr) :: f__set_contracts_static
    type(c_funptr) :: f__dump_stats_static
    type(c_funptr) :: f_vuIsZero
    type(c_funptr) :: f_vuIsUnit
    type(c_funptr) :: f_vuAreEqual
    type(c_funptr) :: f_vuAreOrth
    type(c_funptr) :: f_vuSchwarzHolds
    type(c_funptr) :: f_vuTriIneqHolds
    type(c_funptr) :: f_vuDot
    type(c_funptr) :: f_vuProduct
    type(c_funptr) :: f_vuNegate
    type(c_funptr) :: f_vuNormalize
    type(c_funptr) :: f_vuSum
    type(c_funptr) :: f_vuDiff
  end type
  type, bind(c) :: vect_Utils_epv_t
    type(c_funptr) :: f__cast
    type(c_funptr) :: f__delete
    type(c_funptr) :: f__exec
    type(c_funptr) :: f__getURL
    type(c_funptr) :: f__raddRef
    type(c_funptr) :: f__isRemote
    type(c_funptr) :: f__set_hooks
    type(c_funptr) :: f__set_contracts
    type(c_funptr) :: f__dump_stats
    type(c_funptr) :: f__ctor
    type(c_funptr) :: f__ctor2
    type(c_funptr) :: f__dtor
    type(c_funptr) :: f__load
    type(c_funptr) :: f_addRef
    type(c_funptr) :: f_deleteRef
    type(c_funptr) :: f_isSame
    type(c_funptr) :: f_isType
    type(c_funptr) :: f_getClassInfo
  end type
  type, bind(c) :: vect_Utils_pre_epv_t
    integer(c_int) :: avoid_empty_type
  end type
  type, bind(c) :: vect_Utils_post_sepv_t
    type(c_funptr) :: f_vuIsUnit_post
    type(c_funptr) :: f_vuAreEqual_post
    type(c_funptr) :: f_vuAreOrth_post
    type(c_funptr) :: f_vuSchwarzHolds_post
    type(c_funptr) :: f_vuTriIneqHolds_post
    type(c_funptr) :: f_vuNorm_post
    type(c_funptr) :: f_vuDot_post
    type(c_funptr) :: f_vuProduct_post
    type(c_funptr) :: f_vuNegate_post
    type(c_funptr) :: f_vuNormalize_post
    type(c_funptr) :: f_vuSum_post
    type(c_funptr) :: f_vuDiff_post
  end type
  type, bind(c) :: vect_Utils_pre_sepv_t
    type(c_funptr) :: f_vuIsZero_pre
    type(c_funptr) :: f_vuIsUnit_pre
    type(c_funptr) :: f_vuAreEqual_pre
    type(c_funptr) :: f_vuAreOrth_pre
    type(c_funptr) :: f_vuSchwarzHolds_pre
    type(c_funptr) :: f_vuTriIneqHolds_pre
    type(c_funptr) :: f_vuNorm_pre
    type(c_funptr) :: f_vuDot_pre
    type(c_funptr) :: f_vuProduct_pre
    type(c_funptr) :: f_vuNegate_pre
    type(c_funptr) :: f_vuNormalize_pre
    type(c_funptr) :: f_vuSum_pre
    type(c_funptr) :: f_vuDiff_pre
  end type
  type vect_Utils_t
    type(c_ptr) :: d_ior = c_null_ptr
    type(vect_Utils_epv_t), pointer :: d_epv => null()
  end type vect_Utils_t
  interface cache_epv
    module procedure cache_epv_s
  end interface cache_epv
contains
    subroutine cache_epv_s(self)
      implicit none
      class(vect_Utils_t) :: self
    end subroutine cache_epv_s
end module vect_Utils_type_F03
module vect_Utils_F03
  use vect_Utils_type_F03
interface
  type(c_ptr) function get_sepv_c() bind(c, name="vect_Utils_getSEPV")
  use, intrinsic :: iso_c_binding
  end function get_sepv_c
  integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
    use, intrinsic :: iso_c_binding
  end function vect_Utils_vuIsUnit_c
  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
    use, intrinsic :: iso_c_binding
  real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
  end function vect_Utils_vuNorm_c
end interface
end module vect_Utils_F03

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-02 19:08:19 UTC ---
Sorry, I'm unable to reproduce the ICE with today's trunk. I tried to testcase
in comment #4 with and without the fixes from #3 as well as the original
testcase.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-03 10:50:02 UTC ---
If I try the example of comment 4 with the line break before "&" undone and
using the newest 4.7 trunk (clean build), I see in valgrind:

==14154== Invalid read of size 4
==14154==    at 0x52D345: resolve_symbol (resolve.c:10559)
==14154==    by 0x54131F: do_traverse_symtree (symbol.c:3385)
==14154==    by 0x530093: resolve_types (resolve.c:13859)
==14154==    by 0x5243DB: gfc_resolve (resolve.c:13959)

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-03 22:36:13 UTC ---
(In reply to comment #6)
> If I try the example of comment 4 with the line break before "&" undone and
> using the newest 4.7 trunk (clean build), I see in valgrind:
> 
> ==14154== Invalid read of size 4
> ==14154==    at 0x52D345: resolve_symbol (resolve.c:10559)
> ==14154==    by 0x54131F: do_traverse_symtree (symbol.c:3385)
> ==14154==    by 0x530093: resolve_types (resolve.c:13859)
> ==14154==    by 0x5243DB: gfc_resolve (resolve.c:13959)

Yes, I saw the same thing. But, as I didn't see any relation between
resolve.c:10559 and the r183681 patch, I assumed this was something which was
present before and didn't investigate further. 

Also, looking at the r183681 patch itself at
http://gcc.gnu.org/ml/fortran/2012-01/msg00255.html, I find it difficult to see
how it can cause any problems (*knocking on wood*).

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-02-04 00:19:16 UTC ---
> Yes, I saw the same thing. But, as I didn't see any relation between
> resolve.c:10559 and the r183681 patch, I assumed this was something which was
> present before and didn't investigate further. 

Note that I did not say that the segmentation fault was caused by r183681. I
only said that it reappeared at this revision, in the same way I do not think
the problem has been fixed by r183010, but only hidden.

I have tried some versions I have and found that with r183001 there is no
segmentation fault for the reduced test in comment #4, only the original test
gives it, while for r179630 both give the segmentation fault. Note that I do
not get any segmentation fault for both tests on powerpc-apple-darwin9.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-05 21:04:18 UTC ---
So the complete valgrind error message I get (with the comment #4 testcase
fixed per Tobias instructions in comment #6) is:

==14281== Invalid read of size 4
==14281==    at 0x528B66: resolve_symbol (resolve.c:10559)
==14281==    by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281==    by 0x532503: resolve_types (resolve.c:13859)
==14281==    by 0x527473: gfc_resolve (resolve.c:13959)
==14281==    by 0x528C18: resolve_symbol (resolve.c:12715)
==14281==    by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281==    by 0x532503: resolve_types (resolve.c:13859)
==14281==    by 0x527473: gfc_resolve (resolve.c:13959)
==14281==    by 0x51ABBC: gfc_parse_file (parse.c:4594)
==14281==    by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281==    by 0x909CDC: do_compile (toplev.c:557)
==14281==    by 0x90A853: toplev_main (toplev.c:2014)
==14281==  Address 0x5ca8700 is 32 bytes inside a block of size 304 free'd
==14281==    at 0x4C270BD: free (vg_replace_malloc.c:366)
==14281==    by 0x546E91: gfc_undo_symbols (symbol.c:2898)
==14281==    by 0x514F5A: reject_statement (parse.c:1743)
==14281==    by 0x515A54: decode_statement (parse.c:316)
==14281==    by 0x516D8C: next_statement (parse.c:778)
==14281==    by 0x51801D: parse_spec (parse.c:2379)
==14281==    by 0x51A9BD: gfc_parse_file (parse.c:4297)
==14281==    by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281==    by 0x909CDC: do_compile (toplev.c:557)
==14281==    by 0x90A853: toplev_main (toplev.c:2014)
==14281==    by 0x5712C4C: (below main) (libc-start.c:226)
==14281== 
==14281== Invalid read of size 8
==14281==    at 0x52869D: resolve_symbol (resolve.c:12726)
==14281==    by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281==    by 0x532503: resolve_types (resolve.c:13859)
==14281==    by 0x527473: gfc_resolve (resolve.c:13959)
==14281==    by 0x528C18: resolve_symbol (resolve.c:12715)
==14281==    by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281==    by 0x532503: resolve_types (resolve.c:13859)
==14281==    by 0x527473: gfc_resolve (resolve.c:13959)
==14281==    by 0x51ABBC: gfc_parse_file (parse.c:4594)
==14281==    by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281==    by 0x909CDC: do_compile (toplev.c:557)
==14281==    by 0x90A853: toplev_main (toplev.c:2014)
==14281==  Address 0x5ca87e0 is 256 bytes inside a block of size 304 free'd
==14281==    at 0x4C270BD: free (vg_replace_malloc.c:366)
==14281==    by 0x546E91: gfc_undo_symbols (symbol.c:2898)
==14281==    by 0x514F5A: reject_statement (parse.c:1743)
==14281==    by 0x515A54: decode_statement (parse.c:316)
==14281==    by 0x516D8C: next_statement (parse.c:778)
==14281==    by 0x51801D: parse_spec (parse.c:2379)
==14281==    by 0x51A9BD: gfc_parse_file (parse.c:4297)
==14281==    by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281==    by 0x909CDC: do_compile (toplev.c:557)
==14281==    by 0x90A853: toplev_main (toplev.c:2014)
==14281==    by 0x5712C4C: (below main) (libc-start.c:226)

So the problem seems to be that when we hit the error in the interface
declaration, we call gfc_undo_symbols() -> gfc_release_symbol() ->
gfc_free_symbol() -> free(), but then we go and dereference pointers to this
freed memory.

Unfortunately I'm not really familiar enough with this part of the codebase to
know how to fix it properly.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling various variants of the test with 4.8 up to trunk (6.0) under
valgrind does not give valgrind error (while I get some with 4.5 and 4.6).

Am I missing something?