[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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=gcc=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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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, _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, _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

[dominiq at lps dot ens.fr]

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 with two left thumbs!-(

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[janus at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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

[sgk at troutmask dot apl.washington.edu]

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, _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

[janus at gcc dot gnu.org]

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, _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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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 

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[dominiq at lps dot ens.fr]

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

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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

[janus at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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=gcc=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

[kargl at gcc dot gnu.org]

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

[marxin at gcc dot gnu.org]

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

[gerhard.steinmetz.fort...@t-online.de]

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