http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
Bug #: 55907
Summary: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1418
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: garcia.espinosa...@gmail.com
Compiling the code below as follows produces the following error:
gfortran toto.F -fno-automatic -finit-local-zero
toto.F: In function 'cchaine':
toto.F:9:0: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1418
The code compiles and works correctly with gfortran 4.4.6 in Linux Centos-6
2.6.32-279.el6.x86_64 or 4.3.4 in SUSE-10 2.6.32.12-0.7-default, but not with
gfortran 4.7.1 or 4.7.2 (generated without any particular option flag) in
either platform.
It also works correctly if either compilation flag is removed.
The actual (old, large piece of) code (which used to be compiled with g95) from
which this problem was extracted actually generates a slightly different error
message
f951: internal compiler error: Segmentation fault
which is believed to relate to the same problem... (though a SEGV is not quite
the same outcome as a failed gcc_assert)
When captured by gdb: gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/f951
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 14516]
0x000000000050fa96 in gfc_check_assign (lvalue=0x7fffffffc360,
rvalue=0x1777220, conform=1) at ../../gcc-4.7.2-src/gcc/fortran/expr.c:3158
3158 if (gfc_option.warn_surprising
3159 && rvalue->expr_type == EXPR_FUNCTION
3160 && rvalue->symtree->n.sym->attr.pointer)
where rvalue->symtree = 0x0
and the bt was:
#0 0x000000000050fa96 in gfc_check_assign (lvalue=0x7fffffffc360,
rvalue=0x1777220, conform=1) at ../../gcc-4.7.2-src/gcc/fortran/expr.c:3158
#1 0x0000000000513bdb in gfc_check_assign_symbol (sym=0x1710220,
rvalue=0x1777220) at ../../gcc-4.7.2-src/gcc/fortran/expr.c:3674
#2 0x00000000005796d4 in do_traverse_symtree (st=Unhandled dwarf expression
opcode 0xf3)
at ../../gcc-4.7.2-src/gcc/fortran/symbol.c:3385
#3 0x00000000005661db in resolve_types (ns=0x170ef70)
at ../../gcc-4.7.2-src/gcc/fortran/resolve.c:13880
#4 0x0000000000566168 in resolve_types (ns=0x164b600)
at ../../gcc-4.7.2-src/gcc/fortran/resolve.c:13873
#5 0x000000000055a624 in gfc_resolve (ns=0x164b600)
at ../../gcc-4.7.2-src/gcc/fortran/resolve.c:13962
#6 gfc_resolve (ns=0x164b600)
at ../../gcc-4.7.2-src/gcc/fortran/resolve.c:13950
#7 0x0000000000550433 in gfc_parse_file ()
at ../../gcc-4.7.2-src/gcc/fortran/parse.c:4594
#8 0x000000000058afc6 in gfc_be_parse_file ()
at ../../gcc-4.7.2-src/gcc/fortran/f95-lang.c:250
#9 0x0000000000838c60 in compile_file ()
at ../../gcc-4.7.2-src/gcc/toplev.c:557
#10 do_compile () at ../../gcc-4.7.2-src/gcc/toplev.c:1938
#11 toplev_main () at ../../gcc-4.7.2-src/gcc/toplev.c:2014
#12 0x00007ffff6cc1bc6 in __libc_start_main () from /lib64/libc.so.6
#13 0x00000000004e6d2d in _start () at ../sysdeps/x86_64/elf/start.S:113
While the code + compilation options are a bit of a non-sense, without much
knowledge on why it worked on previous versions, I would say the local variable
chaine with dynamic size should likely be forced to be automatic by the
compiler (override the no-automatic flag).
! gfortran toto.F -fno-automatic -finit-local-zero
! g95 toto.F -fstatic -fzero
program toto
character*30 c_nom
c_nom = "toto"
call cchaine( c_nom )
end program toto
subroutine cchaine( c_nom )
implicit none
character*(*), intent(IN) :: c_nom
character*(len_trim(c_nom) + 20) :: chaine
write(chaine,*) "integer, save ::", trim(c_nom)
write(0,*) chaine
end subroutine cchaine
