$ cat foo.f90 character(len=2.3) :: s print *, len(s) end $ gfortran foo.f90 foo.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type foo.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type foo.f90:0: internal compiler error: Segmentation fault
*** Bug 31414 has been marked as a duplicate of this bug. ***
I am not getting a segfault on this. Maybe it fixed itself? :) [jerry@quasar test]$ gfc pr31251.f90 pr31251.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type pr31251.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type
I see why we are getting two error messages. There is a recursive call going on here, Probably not a good idea. I will see if I can sort this out.
With IMPLICIT NONE the double code path goes away and we get just one correct error message.
Created attachment 13470 [details] Possible patch for this problem The double error comes from trying to match_type_spec for a variable declaration and then later for the prefix for a function declaration. It does this even though there has clearly been a syntax error. I am not able to reproduce a segfault. However, this patch eliminates the double error message. Could someone verify that they still get a segfault without this patch and then try with the patch to see what happens.
(In reply to comment #5) > I am not able to reproduce a segfault. However, this patch eliminates the > double error message. Could someone verify that they still get a segfault > without this patch and then try with the patch to see what happens. It's weird. I have applied your patch and rebuilt but I still get the double error, and the segfault: pr31251.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type pr31251.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type ==3668== ==3668== Invalid read of size 4 ==3668== at 0x86ED6F1: __gmpn_copyi (in /home/fxcoudert/svn/debug2/irun/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951) ==3668== Address 0x2 is not stack'd, malloc'd or (recently) free'd pr31251.f90:0: internal compiler error: Segmentation fault I don't know what the heck is happening here, but I'll try to understand it better in the next few days.
Very odd. On rev 124344 on my old i686 FC5 box I did a bootstrap. This is unmodified source from the svn and I get no segfault and just the double error. This is what I see on x86-64 as reported above.
This appears to be an alignment issue. On x86_64-*-FreeBSD, I do not see the segfault. On i386-*-FreeBSD, I see the segfault. Here's is the backtrace Starting program: /usr/home/kargl/work/4x/libexec/gcc/i386-unknown-freebsd7.0/4.3.0/f951 b.f90 b.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type b.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type Program received signal SIGSEGV, Segmentation fault. 0x287c4cf1 in __gmpn_copyi () from /usr/local/lib/libgmp.so.7 (gdb) bt #0 0x287c4cf1 in __gmpn_copyi () from /usr/local/lib/libgmp.so.7 #1 0x287b5413 in __gmpz_set () from /usr/local/lib/libgmp.so.7 #2 0x0809495b in gfc_simplify_len (e=0x28932260) at ../../gcc4x/gcc/fortran/simplify.c:2143 #3 0x0806ba1d in do_simplify (specific=0x28941b70, e=0x28932200) at ../../gcc4x/gcc/fortran/intrinsic.c:3134 #4 0x0806bde1 in gfc_intrinsic_func_interface (expr=0x28932200, error_flag=680567168) at ../../gcc4x/gcc/fortran/intrinsic.c:3395 #5 0x08089b91 in gfc_resolve_expr (e=0x28932200) at ../../gcc4x/gcc/fortran/resolve.c:1456 #6 0x0808bf4d in resolve_code (code=0x2892c9c0, ns=0x28938000) at ../../gcc4x/gcc/fortran/resolve.c:5091 #7 0x0808d7ee in gfc_resolve_blocks (b=0x2892ca00, ns=0x28938000) at ../../gcc4x/gcc/fortran/resolve.c:5024 #8 0x0808bf31 in resolve_code (code=0x2892ca80, ns=0x28938000) at ../../gcc4x/gcc/fortran/resolve.c:5083 #9 0x0808ee65 in resolve_codes (ns=0x28938000) at ../../gcc4x/gcc/fortran/resolve.c:7386 #10 0x0808ee93 in gfc_resolve (ns=0x28938000) at ../../gcc4x/gcc/fortran/resolve.c:7405 #11 0x08084032 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:3248 #12 0x080a0b10 in gfc_be_parse_file (set_yydebug=0) at ../../gcc4x/gcc/fortran/f95-lang.c:305 #13 0x082b4bcd in toplev_main (argc=2, argv=0xbfbfe8a3) at ../../gcc4x/gcc/toplev.c:1051 #14 0x080d795b in main (argc=2, argv=0xbfbfe734) at ../../gcc4x/gcc/main.c:35
I think the problem may be in arith.c (gfc_constant_result). We are passing a type real into this and so we do not mpz_init (result->value.integer); Which we later try to set at simplify.c: 2143 mpz_set (result->value.integer, e->ts.cl->length->value.integer); And it breaks sometimes. As I said, I can not reproduce the bug, but this is my look into it for what its worth. You might try this and see what it does: Index: arith.c =================================================================== --- arith.c (revision 124405) +++ arith.c (working copy) @@ -420,6 +420,7 @@ gfc_constant_result (bt type, int kind, case BT_REAL: gfc_set_model_kind (kind); + mpz_init (result->value.integer); mpfr_init (result->value.real); break;
Comment #9 is a red herring. Using gdb and looking at this at line 2143: mpz_set (result->value.integer, e->ts.cl->length->value.integer); (gdb) p *e->ts.cl->length $9 = {expr_type = EXPR_CONSTANT, ts = {type = BT_REAL, kind = 4, derived = 0x0, cl = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where = {nextc = 0xef3b0c "2.3) :: s", lb = 0xef3ae0}, from_H = 0, inline_noncopying_intrinsic = 0, con_by_offset = 0x0, value = {logical = 24, integer = {{_mp_alloc = 24, _mp_size = 0, _mp_d = 0x1}}, real = {{ _mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 2, _mpfr_d = 0xf25d08}}, complex = {r = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 2, _mpfr_d = 0xf25d08}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {operator = 24, uop = 0x1, op1 = 0x2, op2 = 0xf25d08}, function = {actual = 0x18, name = 0x1 <Address 0x1 out of bounds>, isym = 0x2, esym = 0xf25d08}, character = {length = 24, string = 0x1 <Address 0x1 out of bounds>}, constructor = 0x18}} The type is real and we are trying to use the value.integer which is probably meaningless. Again, I am unable to really test this, but here is a suggestion: Index: simplify.c =================================================================== --- simplify.c (revision 124405) +++ simplify.c (working copy) @@ -2136,14 +2136,15 @@ gfc_simplify_len (gfc_expr *e) } if (e->ts.cl != NULL && e->ts.cl->length != NULL - && e->ts.cl->length->expr_type == EXPR_CONSTANT) + && e->ts.cl->length->expr_type == EXPR_CONSTANT + && e->ts.cl->length->ts.type == BT_INTEGER) { result = gfc_constant_result (BT_INTEGER, gfc_default_integer_kind, &e->where); mpz_set (result->value.integer, e->ts.cl->length->value.integer); return range_check (result, "LEN"); } - + return NULL; }
(In reply to comment #10) > Again, I am unable to really test this, but here is a suggestion This patch fixes the ICE, and I agree it's the right thing to do. I retested your other patch from scratch (the one to decl.c) and it doesn't fix the double-error problem. Maybe your forgot some part of it?
Subject: Bug 31251 Author: fxcoudert Date: Fri May 4 11:10:06 2007 New Revision: 124415 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124415 Log: PR fortran/31251 * simplify.c (gfc_simplify_len): Only simplify integer lengths. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
I noticed after applying the patch to simplify.c the double error problem returned. I will continue on that part. Subtle things going on here. Side effects. At least we have the segfault resolved.
Now I have tracked that we have a duplicate expr in the cl_list so that we call resolve_char_len twice, as the list is traversed in resolve_types. A quick fix is to bail out of the loop if resolve_char_len returns FAILURE. However, I would like to know how we get the duplication in the first place and fix that.
The problems is due to trying to match a prefix to a function declaration or a variable declaration. Both code paths find the error. I have a tentative patch. It might not be worth it. We will see after I complete testing.
Subject: Bug number PR31251 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00298.html
Subject: Bug 31251 Author: jvdelisle Date: Sun May 6 04:10:53 2007 New Revision: 124469 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124469 Log: 2007-05-05 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/31251 * decl.c (match_char_spec): Add check for invalid character lengths. 2007-05-05 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/31251 * gfortran.dg/char_type_len_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_type_len_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
Fixed on 4.3