[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #33 from janus at gcc dot gnu.org --- (In reply to janus from comment #30) > It might even be a good idea to merge the two functions into one, in order > to get rid of the code duplication. But I'm not sure if there are any > obstacles. Will open a follow-up PR to investigate this. I have opened PR 78674 for this.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 janus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #32 from janus at gcc dot gnu.org --- r243232 should fix the failure of char_conversion.f90, so I'm closing this PR for good.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #31 from janus at gcc dot gnu.org --- Author: janus Date: Sun Dec 4 20:31:26 2016 New Revision: 243232 URL: https://gcc.gnu.org/viewcvs?rev=243232&root=gcc&view=rev Log: 2016-12-04 Janus Weil PR fortran/78618 * intrinsic.c (gfc_convert_type_warn): Do not set the full typespec for the conversion symbol, but only type and kind. Set the full typespec for the expression. (gfc_convert_chartype): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #30 from janus at gcc dot gnu.org --- (In reply to janus from comment #29) > I'm now regtesting this: No failures! Will commit this soon. For gfc_convert_type_warn the changes are possibly not really necessary (since it deals with non-char types which normally do not have a charlen), but they do not hurt either. It might even be a good idea to merge the two functions into one, in order to get rid of the code duplication. But I'm not sure if there are any obstacles. Will open a follow-up PR to investigate this.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #29 from janus at gcc dot gnu.org --- I'm now regtesting this: Index: gcc/fortran/intrinsic.c === --- gcc/fortran/intrinsic.c (revision 243224) +++ gcc/fortran/intrinsic.c (working copy) @@ -4984,12 +4984,14 @@ gfc_convert_type_warn (gfc_expr *expr, gfc_typespe new_expr->value.function.name = sym->lib_name; new_expr->value.function.isym = sym; new_expr->where = old_where; + new_expr->ts = *ts; new_expr->rank = rank; new_expr->shape = gfc_copy_shape (shape, rank); gfc_get_ha_sym_tree (sym->name, &new_expr->symtree); new_expr->symtree->n.sym->result = new_expr->symtree->n.sym; - new_expr->symtree->n.sym->ts = *ts; + new_expr->symtree->n.sym->ts.type = ts->type; + new_expr->symtree->n.sym->ts.kind = ts->kind; new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE; new_expr->symtree->n.sym->attr.function = 1; new_expr->symtree->n.sym->attr.elemental = 1; @@ -5055,11 +5057,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec new_expr->value.function.name = sym->lib_name; new_expr->value.function.isym = sym; new_expr->where = old_where; + new_expr->ts = *ts; new_expr->rank = rank; new_expr->shape = gfc_copy_shape (shape, rank); gfc_get_ha_sym_tree (sym->name, &new_expr->symtree); - new_expr->symtree->n.sym->ts = *ts; + new_expr->symtree->n.sym->ts.type = ts->type; + new_expr->symtree->n.sym->ts.kind = ts->kind; new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE; new_expr->symtree->n.sym->attr.function = 1; new_expr->symtree->n.sym->attr.elemental = 1;
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #28 from Dominique d'Humieres --- > Do you mean gfc_convert_type_warn? Yes, copy&paste with two left thumbs!-(
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #27 from Steve Kargl --- On Sun, Dec 04, 2016 at 07:17:52PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #25 from Dominique d'Humieres --- > Confirmed here too! > > There is a similar construct for gfc_convert_chartype. Should not the same > patch apply there too? > Do you mean gfc_convert_type_warn? The answer is 'probably, yes'.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #26 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #25) > There is a similar construct for gfc_convert_chartype. Should not the same > patch apply there too? I guess you mean gfc_convert_type_warn? gfc_convert_chartype is what my patch in comment 21 deals with. Except for this confusion, you're probably right ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #25 from Dominique d'Humieres --- Confirmed here too! There is a similar construct for gfc_convert_chartype. Should not the same patch apply there too?
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #24 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #23) > > This fixes the SIGSEGV on i686-*-freebsd. I'm starting > > a full regression test now. I think you found the > > solution! > > Regression testing on x86_64-*-freebsd completed. > It seems that you've found the fix. Patch is OK > to commit. Great! Thank god we finally nailed this one. Will commit soon ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #23 from Steve Kargl --- On Sun, Dec 04, 2016 at 06:43:08PM +, sgk at troutmask dot apl.washington.edu wrote: > > This fixes the SIGSEGV on i686-*-freebsd. I'm starting > a full regression test now. I think you found the > solution! Regression testing on x86_64-*-freebsd completed. It seems that you've found the fix. Patch is OK to commit. Thanks for in the dark on this issue.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #22 from Steve Kargl --- On Sun, Dec 04, 2016 at 06:01:29PM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #21 from janus at gcc dot gnu.org --- > (In reply to janus from comment #20) > > So I guess one should find out where the symbol '__convert_s4_s1' obtains > > its charlen and prevent that from happening ... > > > I think that this is accomplished by the following: > > Index: gcc/fortran/intrinsic.c > === > --- gcc/fortran/intrinsic.c (revision 243224) > +++ gcc/fortran/intrinsic.c (working copy) > @@ -5055,11 +5055,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec >new_expr->value.function.name = sym->lib_name; >new_expr->value.function.isym = sym; >new_expr->where = old_where; > + new_expr->ts = *ts; >new_expr->rank = rank; >new_expr->shape = gfc_copy_shape (shape, rank); > >gfc_get_ha_sym_tree (sym->name, &new_expr->symtree); > - new_expr->symtree->n.sym->ts = *ts; > + new_expr->symtree->n.sym->ts.type = ts->type; > + new_expr->symtree->n.sym->ts.kind = ts->kind; >new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE; >new_expr->symtree->n.sym->attr.function = 1; >new_expr->symtree->n.sym->attr.elemental = 1; > > > Could someone please check if that helps? > This fixes the SIGSEGV on i686-*-freebsd. I'm starting a full regression test now. I think you found the solution!
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #21 from janus at gcc dot gnu.org --- (In reply to janus from comment #20) > So I guess one should find out where the symbol '__convert_s4_s1' obtains > its charlen and prevent that from happening ... I think that this is accomplished by the following: Index: gcc/fortran/intrinsic.c === --- gcc/fortran/intrinsic.c (revision 243224) +++ gcc/fortran/intrinsic.c (working copy) @@ -5055,11 +5055,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec new_expr->value.function.name = sym->lib_name; new_expr->value.function.isym = sym; new_expr->where = old_where; + new_expr->ts = *ts; new_expr->rank = rank; new_expr->shape = gfc_copy_shape (shape, rank); gfc_get_ha_sym_tree (sym->name, &new_expr->symtree); - new_expr->symtree->n.sym->ts = *ts; + new_expr->symtree->n.sym->ts.type = ts->type; + new_expr->symtree->n.sym->ts.kind = ts->kind; new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE; new_expr->symtree->n.sym->attr.function = 1; new_expr->symtree->n.sym->attr.elemental = 1; Could someone please check if that helps?
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #20 from janus at gcc dot gnu.org --- Possibly the origin of the problem lies in the fact that the symbol '__convert_s4_s1' gets a constant ts.u.cl of '1' after all? IIUC __convert_s4_s1 is used to convert character strings of any length. So any expression involving this function can have a constant charlen (which equals to the charlen of the function argument). But the function symbol itself does not have a particular charlen associated with it, since it can be applied to different arguments, right? So I guess one should find out where the symbol '__convert_s4_s1' obtains its charlen and prevent that from happening ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #19 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #18) > On Sun, Dec 04, 2016 at 04:24:21PM +, janus at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > > > Maybe one can instead try to nullify the memory in gfc_free charlen, so > > that we > > at least know that cl->lengh is not a valid pointer? (Something similar is > > also > > done in gfc_free_expr / free_expr0 in expr.c.) > > > > Index: symbol.c > > === > > --- symbol.c(revision 243224) > > +++ symbol.c(working copy) > > @@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en > > > >cl2 = cl->next; > >gfc_free_expr (cl->length); > > + memset (cl, '\0', sizeof (gfc_charlen)); > >free (cl); > > } > > } > > > > Doesn't that leak memory? The 'free(cl)' in the line > after memset() should be a NOP, so whatever cl pointed > to before the memset() is leaked. I guess memset does not nullify the pointer 'cl' itself, but the memory it points to, right? (As mentioned, we do the same thing in gfc_free_expr.) > Hmmm, doesn't seem to help. Too bad :(
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #18 from Steve Kargl --- On Sun, Dec 04, 2016 at 04:24:21PM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > Maybe one can instead try to nullify the memory in gfc_free charlen, so that > we > at least know that cl->lengh is not a valid pointer? (Something similar is > also > done in gfc_free_expr / free_expr0 in expr.c.) > > Index: symbol.c > === > --- symbol.c(revision 243224) > +++ symbol.c(working copy) > @@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en > >cl2 = cl->next; >gfc_free_expr (cl->length); > + memset (cl, '\0', sizeof (gfc_charlen)); >free (cl); > } > } > Doesn't that leak memory? The 'free(cl)' in the line after memset() should be a NOP, so whatever cl pointed to before the memset() is leaked. Hmmm, doesn't seem to help. Setting a break point in gdb at gfc_free_charlen, I see Breakpoint 1, gfc_free_charlen (cl=0x0, end=0x0) at /mnt/kargl/gcc/gcc/fortran/symbol.c:3832 3832{ (gdb) Continuing. Program received signal SIGSEGV, Segmentation fault. gfc_is_constant_expr (e=0x193e) at /mnt/kargl/gcc/gcc/fortran/expr.c:897 897 switch (e->expr_type) Note, gfc_charlen_free() was called 43 times before the SIGSEGV. In only one call, cl was non-NULL.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #16) > Index: resolve.c > === > --- resolve.c (revision 243227) > +++ resolve.c (working copy) > @@ -12010,6 +12010,9 @@ resolve_fl_procedure (gfc_symbol *sym, i > { >gfc_charlen *cl = sym->ts.u.cl; > > + if (strcmp (sym->name, "__convert_s4_s1") == 0) > + return false; > + >if (cl && cl->length && gfc_is_constant_expr (cl->length) > && !resolve_charlen (cl)) > return false; > > It's not pretty, but seems to work. :( I don't really think that sort of workaround is a good idea. Maybe one can instead try to nullify the memory in gfc_free charlen, so that we at least know that cl->lengh is not a valid pointer? (Something similar is also done in gfc_free_expr / free_expr0 in expr.c.) Index: symbol.c === --- symbol.c(revision 243224) +++ symbol.c(working copy) @@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en cl2 = cl->next; gfc_free_expr (cl->length); + memset (cl, '\0', sizeof (gfc_charlen)); free (cl); } } Steve, could you check if this fixes the ICE?
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #16 from Steve Kargl --- On Sun, Dec 04, 2016 at 10:07:16AM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #15 from janus at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #10) > > This looks like a used-after-freed bug. > > Yes, it does. > > My first suspicion was that the problematic freeing happens at the end of > variable_decl (decl.c:2450): > > gfc_free_expr (initializer); > > It seems the initializer here has the same ts.u.cl (not a copy) as the symbol > 'c'. However, gfc_free_expr (surprisingly) does not free anything in the > typespec. > > Instead it seems the charlen is freed via gfc_free_charlen in > 'reject_statement'. Not sure what to do about it ... > Looks like you have done a nice bit of debugging. I went in a different direction. In intrinsic.c (gfc_convert_chartype), I tried to allocate a gfc_charlen and then copy ts.u.cl from the char(255,4) in the ts.u.cl for 'c'. This occurs before 'reject_statement', so of course it failed. I've a possible kludge under testing. In resolve.c (resolve_fl_procedure), the offending chunk of code is (line 12013 or so) if (cl && cl->length && gfc_is_constant_expr (cl->length) && !resolve_charlen (cl)) return false; where cl->length is invalid but not NULL. I simply forced a 'return false' in gdb to see what would happen, and char_constant.f90 compiled without the ICE error. Thus, I've came up with Index: resolve.c === --- resolve.c (revision 243227) +++ resolve.c (working copy) @@ -12010,6 +12010,9 @@ resolve_fl_procedure (gfc_symbol *sym, i { gfc_charlen *cl = sym->ts.u.cl; + if (strcmp (sym->name, "__convert_s4_s1") == 0) + return false; + if (cl && cl->length && gfc_is_constant_expr (cl->length) && !resolve_charlen (cl)) return false; It's not pretty, but seems to work. :(
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #10) > This looks like a used-after-freed bug. Yes, it does. My first suspicion was that the problematic freeing happens at the end of variable_decl (decl.c:2450): gfc_free_expr (initializer); It seems the initializer here has the same ts.u.cl (not a copy) as the symbol 'c'. However, gfc_free_expr (surprisingly) does not free anything in the typespec. Instead it seems the charlen is freed via gfc_free_charlen in 'reject_statement'. Not sure what to do about it ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #14 from Dominique d'Humieres --- Using a gfortran configured with: ../work/configure --prefix=/opt/gcc/gcc7g --enable-languages=c,c++,fortran --with-gmp=/opt/mp-new --with-system-zlib --with-isl=/opt/mp-new --disable-bootstrap --disable-multilib --disable-libstdcxx CFLAGS='-L/opt/gcc/gcc7a/lib -lasan -lubsan -fsanitize=address,undefined,leak -Og -g -fno-omit-frame-pointer' CXXFLAGS='-fsanitize=address,undefined,leak -Og -g -fno-omit-frame-pointer' LDFLAGS='-L/opt/gcc/gcc7a/lib -lasan -lubsan -ldl -lpthread' I get /opt/gcc/_clean/gcc/testsuite/gfortran.dg/char_conversion.f90:8:30: character, parameter :: c = char(256,4) ! { dg-error "cannot be converted" } 1 Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 = ==91770==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400f10 at pc 0x000106a8ba7a bp 0x7fff5fbfe790 sp 0x7fff5fbfe788 READ of size 8 at 0x60400f10 thread T0 #0 0x106a8ba79 in resolve_fl_procedure(gfc_symbol*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106a8ba79) #1 0x10030fca5 in resolve_symbol(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10030fca5) #2 0x1003ad42a in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1003ad42a) #3 0x1003c5ff4 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1003c5ff4) #4 0x1003562e3 in resolve_types(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1003562e3) #5 0x1003050b4 in gfc_resolve(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1003050b4) #6 0x10028b192 in resolve_all_program_units(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10028b192) #7 0x1002a78c7 in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1002a78c7) #8 0x1004059e7 in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1004059e7) #9 0x104b213a0 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b213a0) #10 0x104b29e39 in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b29e39) #11 0x106c1094e in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c1094e) #12 0x106c15c67 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c15c67) #13 0x7fffe8d83254 in start (/usr/lib/system/libdyld.dylib+0x5254) 0x60400f10 is located 0 bytes inside of 48-byte region [0x60400f10,0x60400f40) freed by thread T0 here: #0 0x152b7d8b0 in wrap_free.part.0 (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x638b0) #1 0x1003c4e30 in gfc_free_charlen(gfc_charlen*, gfc_charlen*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1003c4e30) #2 0x10028c005 in reject_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10028c005) #3 0x10028c3a9 in match_word(char const*, match (*)(), locus*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10028c3a9) #4 0x100296fe6 in decode_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x100296fe6) #5 0x1002995b9 in next_free() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1002995b9) #6 0x10029a0ec in next_statement() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10029a0ec) #7 0x10029f4c6 in parse_spec(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x10029f4c6) #8 0x1002a5827 in parse_progunit(gfc_statement) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1002a5827) #9 0x1002a7820 in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1002a7820) #10 0x1004059e7 in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x1004059e7) #11 0x104b213a0 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b213a0) #12 0x104b29e39 in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x104b29e39) #13 0x106c1094e in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c1094e) #14 0x106c15c67 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/f951+0x106c15c67) #15 0x7fffe8d83254 in start (/usr/lib/system/libdyld.dylib+0x5254) previously allocated by thread T0 here: #0 0x152b7cf30 in wrap_calloc (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x62f30) #1 0x1069d26eb i
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #13 from Dominique d'Humieres --- I also get /opt/gcc/_clean/gcc/testsuite/gfortran.dg/char_conversion.f90:8:30: character, parameter :: c = char(256,4) ! { dg-error "cannot be converted" } 1 Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 f951: internal compiler error: Segmentation fault: 11 on darwin.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #12 from Steve Kargl --- On Sat, Dec 03, 2016 at 09:02:39AM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #11 from janus at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #10) > > Others are see the failures. > > > > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00313.html > > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00311.html > > Not sure why I don't see this. Doing a full bootstrap does not seem to help > either. > > > > I think your patch is correct, but uncovering a new latent bug. > > Does your memory allocator fill freed memory with junk? > > Not sure. How can I tell? Probably need to check the malloc manpage. FreeBSD uses jemalloc and it can be configured to aid in debugging. But, this typically causes a performance issue (as you might imagine). It is perhaps easier to use valgrind. valgrind $PATH_TO/f951 char_conversion.f90 ... Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 ==92206== Invalid read of size 8 ==92206==at 0x658EB4: resolve_fl_procedure (resolve.c:12013) ==92206==by 0x658EB4: resolve_symbol(gfc_symbol*) (resolve.c:14721) ... ==92206== Address 0x638e130 is 0 bytes inside a block of size 48 free'd ==92206==at 0x4C25DCB: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==92206==by 0x67B92B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3841) ... ==92206== Invalid read of size 4 ==92206==at 0x5F0682: gfc_is_constant_expr(gfc_expr*) (expr.c:899) ==92206==by 0x658EC1: resolve_fl_procedure (resolve.c:12013) ... ==92206== Address 0x638e1a0 is 0 bytes inside a block of size 192 free'd ==92206==at 0x4C25DCB: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==92206==by 0x67B923: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3840) > > It's kind of hard to debug this without being able to reproduce the problem > ... > I understand, and I certainly don't expect you to fix this. I think your patch is correct.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #10) > Others are see the failures. > > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00313.html > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00311.html Not sure why I don't see this. Doing a full bootstrap does not seem to help either. > I think your patch is correct, but uncovering a new latent bug. > Does your memory allocator fill freed memory with junk? Not sure. How can I tell? It's kind of hard to debug this without being able to reproduce the problem ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #10 from Steve Kargl --- On Sat, Dec 03, 2016 at 07:31:21AM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #9 from janus at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #8) > > Note, I configured gcc with > > > > ../gcc7/configure \ > > --prefix=$HOME/work/7 --with-isl=/usr/local \ > > --enable-languages=c,fortran,c++ --enable-libsanitizer \ > > --disable-libmudflap --disable-nls > > I'm configuring with > > --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu --with-arch=haswell --prefix=/us > r --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,fortran > --disable-bootstrap --disable-multilib > > I admit that's not a full bootstrap, but I see things working on two different > machines. The testsuite is clean and compiling the test case by hand works as > well. > Others are see the failures. https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00313.html https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00311.html I think your patch is correct, but uncovering a new latent bug. Does your memory allocator fill freed memory with junk? This looks like a used-after-freed bug.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #8) > Note, I configured gcc with > > ../gcc7/configure \ > --prefix=$HOME/work/7 --with-isl=/usr/local \ > --enable-languages=c,fortran,c++ --enable-libsanitizer \ > --disable-libmudflap --disable-nls I'm configuring with --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-arch=haswell --prefix=/us r --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,fortran --disable-bootstrap --disable-multilib I admit that's not a full bootstrap, but I see things working on two different machines. The testsuite is clean and compiling the test case by hand works as well.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #8 from Steve Kargl --- On Fri, Dec 02, 2016 at 10:49:12PM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #7 from janus at gcc dot gnu.org --- > (In reply to kargl from comment #6) > > I updated my source tree to r243203, which includes your change. > > My source tree cuurently has no other changes. I still see an ICE. > > Sorry, I can not reproduce that with my build on x86_64-linux-gnu ... > I anticipated that that would be your response. :-) Note, I configured gcc with ../gcc7/configure \ --prefix=$HOME/work/7 --with-isl=/usr/local \ --enable-languages=c,fortran,c++ --enable-libsanitizer \ --disable-libmudflap --disable-nls Perhaps, I need to re-do a full bootstrap. In the meantime, I poking around to see what's happening.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to kargl from comment #6) > I updated my source tree to r243203, which includes your change. > My source tree cuurently has no other changes. I still see an ICE. Sorry, I can not reproduce that with my build on x86_64-linux-gnu ...
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 kargl at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from kargl at gcc dot gnu.org --- Janus, I updated my source tree to r243203, which includes your change. My source tree cuurently has no other changes. I still see an ICE. However, an error message is printed. troutmask:sgk[232] gfc7 -o z char_conversion.f90 char_conversion.f90:8:30: character, parameter :: c = char(256,4) ! { dg-error "cannot be converted" } 1 Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 f951: internal compiler error: Segmentation fault 0xbb020f crash_signal ../../gcc7/gcc/toplev.c:333 0x5f0662 gfc_is_constant_expr(gfc_expr*) ../../gcc7/gcc/fortran/expr.c:899 0x658e21 resolve_fl_procedure ../../gcc7/gcc/fortran/resolve.c:12013 0x658e21 resolve_symbol ../../gcc7/gcc/fortran/resolve.c:14721 0x67755b do_traverse_symtree ../../gcc7/gcc/fortran/symbol.c:3994 0x6523a4 resolve_types ../../gcc7/gcc/fortran/resolve.c:15948 0x656b2c gfc_resolve(gfc_namespace*) ../../gcc7/gcc/fortran/resolve.c:16061 0x645ef4 resolve_all_program_units ../../gcc7/gcc/fortran/parse.c:5977 0x645ef4 gfc_parse_file() ../../gcc7/gcc/fortran/parse.c:6224 0x68a3c2 gfc_be_parse_file ../../gcc7/gcc/fortran/f95-lang.c:202 Running f951 under gdb shows (gdb) run char_conversion.f90 Starting program: /mnt/sgk/work/7/libexec/gcc/x86_64-unknown-freebsd12.0/7.0.0/f951 char_conversion.f90 char_conversion.f90:8:30: character, parameter :: c = char(256,4) ! { dg-error "cannot be converted" } 1 Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 Program received signal SIGSEGV, Segmentation fault. gfc_is_constant_expr (e=0x193e) at ../../gcc7/gcc/fortran/expr.c:899 899 switch (e->expr_type) 0x193e is certainly an invalid pointer. (gdb) up #1 0x00658e22 in resolve_fl_procedure (mp_flag=0, sym=0x203636180) at ../../gcc7/gcc/fortran/resolve.c:12013 12013 if (cl && cl->length && gfc_is_constant_expr (cl->length) (gdb) p *sym $1 = {name = 0x20382c9d0 "__convert_s4_s1", (gdb) p *sym->ts.u.cl $4 = {length = 0x193e, next = 0x0, length_from_typespec = false, backend_decl = 0x2039d5020, passed_length = 0x0, resolved = 56844352}
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #5 from janus at gcc dot gnu.org --- Fixed with r243201. Closing.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #4 from janus at gcc dot gnu.org --- Author: janus Date: Fri Dec 2 18:38:24 2016 New Revision: 243201 URL: https://gcc.gnu.org/viewcvs?rev=243201&root=gcc&view=rev Log: 2016-12-02 Janus Weil Steven G. Kargl PR fortran/78618 * check.c (gfc_check_rank): Remove ATTRIBUTE_UNUSED. * expr.c (gfc_check_assign): Fix error propagation. 2016-12-02 Steven G. Kargl PR fortran/78618 * gfortran.dg/char_conversion.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_conversion.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- This fixes the ICE. It does not produce the error in assigning an out-of-range kind=4 character to a kind=1 character. Index: gcc/fortran/check.c === --- gcc/fortran/check.c (revision 243142) +++ gcc/fortran/check.c (working copy) @@ -3667,7 +3667,7 @@ gfc_check_range (gfc_expr *x) bool -gfc_check_rank (gfc_expr *a ATTRIBUTE_UNUSED) +gfc_check_rank (gfc_expr *a) { /* Any data object is allowed; a "data object" is a "constant (4.1.3), variable (6), or subobject of a constant (2.4.3.2.3)" (F2008, 1.3.45). */ @@ -3676,9 +3676,16 @@ gfc_check_rank (gfc_expr *a ATTRIBUTE_UN /* Functions returning pointers are regarded as variable, cf. F2008, R602. */ if (a->expr_type == EXPR_FUNCTION) -is_variable = a->value.function.esym - ? a->value.function.esym->result->attr.pointer - : a->symtree->n.sym->result->attr.pointer; +{ + if (a->value.function.esym) + is_variable = a->value.function.esym->result->attr.pointer; + else if (a->symtree->n.sym->result) + is_variable = a->symtree->n.sym->result->attr.pointer; + else if (a->symtree->n.sym->value) + is_variable = true; + else + gfc_internal_error ("gfc_check_rank(): invalid function result"); +} if (a->expr_type == EXPR_OP || a->expr_type == EXPR_NULL || a->expr_type == EXPR_COMPCALL|| a->expr_type == EXPR_PPC
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started to fail with GCC 4.7.0.
[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 --- Comment #1 from Gerhard Steinmetz --- Working variants : $ cat z2.f90 program p character :: c = char(256,4) print *, rank(c) end $ gfortran-7-20161127 z2.f90 z2.f90:2:19: character :: c = char(256,4) 1 Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 $ cat z3.f90 program p character, parameter :: c = char(255,4) print *, rank(c) end $ gfortran-7-20161127 z3.f90 $ a.out 0