------- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2010-07-20 23:35 -------
Subject: Re: gfortran.dg/allocate_with_typespec.f90 failed
On Tue, Jul 20, 2010 at 02:41:01PM -0000, burnus at gcc dot gnu dot org wrote:
>
> gfortran.dg/allocate_with_typespec.f90 shows on x86-64-linux (-m64):
>
> gfortran.dg/allocate_with_typespec.f90:25:0: internal compiler error:
> Segmentation fault
>
> ==11535== Invalid read of size 8
> ==11535== at 0x542506: gfc_delete_symtree (symbol.c:2390)
> ==11535== by 0x543506: gfc_undo_symbols (symbol.c:2862)
> ==11535== by 0x5127E4: decode_statement (parse.c:272)
> ==11535== by 0x5143C4: next_statement (parse.c:727)
> ==11535== by 0x517EAE: gfc_parse_file (parse.c:4307)
> ==11535== by 0x54E447: gfc_be_parse_file (f95-lang.c:236)
> ==11535== by 0x83E279: toplev_main (toplev.c:978)
> ==11535== by 0x6569B7C: (below main) (in /lib64/libc-2.11.2.so)
>
The attached patch restores the order of the old match_type_spec.
It uses gfc_match(" %n ", name) to retrieve the next symbol
from the file and uses strcmp to check against intrinsics
types. Thus, for allocate_with_typespec.f90, when name=real_type
the comparison fails, and we fall through to the matching for
a derived type by match_derived_type_spec(). I did not
write match_derived_type_spec() and have no idea how it works.
The prolific valgrind output that I see I believe is related
to match_derived_type_spec(). I've also attached the
valgrind log.
------- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2010-07-20 23:35 -------
Created an attachment (id=21272)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21272&action=view)
------- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2010-07-20 23:35 -------
Created an attachment (id=21273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21273&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45005
