[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.6 regression] ICE in     |[4.6/4.7 regression] ICE in
                   |gfc_typenode_for_spec, at   |gfc_typenode_for_spec, at
                   |fortran/trans-types.c:1019  |fortran/trans-types.c:1019

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-09 16:57:11 UTC ---
There is something odd about "signal":

Breakpoint 1, gfc_get_extern_function_decl (sym=0x15a19d0) at
/projects/tob/gcc-git/gcc/gcc/fortran/trans-decl.c:1542

(gdb) p sym->name
$11 = 0x2aaaacec0780 "_gfortran_signal_func"
(gdb) p sym->attr.intrinsic 
$1 = 0
(gdb) p sym->attr.external 
$2 = 1
(gdb) p sym->attr.function
$3 = 1
(gdb) p sym->formal->next->sym->name
$8 = 0x2aaaacde3fa0 "handler"
(gdb) p sym->formal->next->sym->ts.type
$17 = BT_UNKNOWN

Thus, the problem is that SIGNAL's handler is BT_UNKNOWN.

One/the question is: Why is SIGNAL not attr.intrinsic?
Cf. http://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html

Just adding attr.intrinsic wouldn't help as then one would lookup
gfc_find_function, which fails for "_gfortran_signal_func". (One would have to
search for "signal".)