Found via a typo and missing -pedantic in gfortran.dg/parameter_array_init_4.f90 $ gfortran -pedantic gfortran.dg/parameter_array_init_4.f90 parameter_array_init_4.f90:18.45: PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) ) 1 Warning: CHARACTER(*) function '__convert_s1_s4' at (1) is obsolescent in fortran 95 Expected: No warning message for internal functions. See resolve.c: if (sym->attr.function && sym->ts.type == BT_CHARACTER && sym->ts.cl && sym->ts.cl->length == NULL) { [...] /* Appendix B.2 of the standard. Contained functions give an error anyway. Fixed-form is likely to be F77/legacy. */ if (!sym->attr.contained && gfc_current_form != FORM_FIXED) gfc_notify_std (GFC_STD_F95_OBS, "CHARACTER(*) function " "'%s' at %L is obsolescent in fortran 95", sym->name, &sym->declared_at); Test case: CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4 PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) )
I love that one: "Fixed-form is likely to be F77/legacy." Well, the issue is that I don't think we have a way to tell, from the sym, that it's a "internal" conversion function. Maybe the crude way, check if the name starts with "__convert_"?
*** Bug 36535 has been marked as a duplicate of this bug. ***
Note: The test case parameter_array_init_4.f90 (Rev. 137950) now avoids the conversion by using kind-4 literals. However, the bug itself is still present. See example in comment #0.
One could work around the bug: As such conversions are not valid, one just needs to reject them with -pedantic (cf. PR 37173) ;-)
It looks like this is fixed. I could not reproduce the problem.
$ cat huhu.f90 CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4 PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) ) end $ gfortran huhu.f90 huhu.f90:1.54: CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4 1 Error: Entity with assumed character length at (1) must be a dummy argument or a PARAMETER Changing the len=* to len=1 removes that error. Let's commit a modified test case and close the bug.
(In reply to comment #5) > It looks like this is fixed. I could not reproduce the problem. I still get this problem: $ cat fhjfff.f90 CHARACTER (kind=4,len=*) MY_STRING4(1:3) PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) ) end $ gfortran -pedantic fhjfff.f90 fhjfff.f90:2.45: PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) ) 1 Warning: Obsolescent feature: CHARACTER(*) function '__convert_s1_s4' at (1)
I can not reproduce at all. Can you try an update. Maybe one our patches recently fixed this.
OK we have a Heisenbug going on here. Running from Valgrind like this: valgrind --leak-check=full f951 -pedantic <untitled.f ==14463== Memcheck, a memory error detector. ==14463== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==14463== Using LibVEX rev 1804, a library for dynamic binary translation. ==14463== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==14463== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==14463== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==14463== For more details, rerun with: -v ==14463== Warning: Reading file '<stdin>' as free form .file "<stdin>" :2.51: PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) ) 1 Warning: Obsolescent feature: CHARACTER(*) function '__convert_s1_s4' at (1) ---- snip ---- ==14463== 316 bytes in 2 blocks are definitely lost in loss record 2 of 6 ==14463== at 0x4A05174: calloc (vg_replace_malloc.c:397) ==14463== by 0xCD3CA8: xcalloc (xmalloc.c:162) ==14463== by 0x629AF4: init_emit (emit-rtl.c:5565) ==14463== by 0x6C2CB7: prepare_function_start (function.c:4169) ==14463== by 0x6C2D58: init_function_start (function.c:4217) ==14463== by 0x53B5FD: trans_function_start (trans-decl.c:1925) ==14463== by 0x5423FE: gfc_generate_function_code (trans-decl.c:4272) ==14463== by 0x4EF4F3: gfc_parse_file (parse.c:4223) ==14463== by 0x52587C: gfc_be_parse_file (f95-lang.c:239) ==14463== by 0x81B205: toplev_main (toplev.c:1049) ==14463== by 0x3F6841E329: (below main) (libc-start.c:220) ==14463== ==14463== LEAK SUMMARY: ==14463== definitely lost: 316 bytes in 2 blocks. ==14463== possibly lost: 64 bytes in 2 blocks. ==14463== still reachable: 423,076 bytes in 1,336 blocks. ==14463== suppressed: 0 bytes in 0 blocks. ==14463== Reachable blocks (those to which a pointer was found) are not shown. ==14463== To see them, rerun with: --leak-check=full --show-reachable=yes
With current trunk (4.6) I see this: $ valgrind --leak-check=full f951 parameter_array_init_4.f90 --- snip --- ==12209== 48 bytes in 6 blocks are definitely lost in loss record 21 of 352 ==12209== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==12209== by 0x36F3809F38: __gmp_default_allocate (in /usr/lib64/libgmp.so.3.5.0) ==12209== by 0x36F381A17D: __gmpz_init_set (in /usr/lib64/libgmp.so.3.5.0) ==12209== by 0x4B20C9: gfc_copy_shape (expr.c:373) ==12209== by 0x4B2353: gfc_copy_expr (expr.c:556) ==12209== by 0x4B5567: simplify_parameter_variable (expr.c:1633) ==12209== by 0x4B5317: gfc_simplify_expr (expr.c:1744) ==12209== by 0x4B5236: gfc_simplify_expr (expr.c:882) ==12209== by 0x4FE188: resolve_operator (resolve.c:3584) ==12209== by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== by 0x4FDFF2: resolve_operator (resolve.c:3316) ==12209== by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== ==12209== 72 bytes in 9 blocks are definitely lost in loss record 202 of 352 ==12209== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==12209== by 0x36F3809F38: __gmp_default_allocate (in /usr/lib64/libgmp.so.3.5.0) ==12209== by 0x36F381A17D: __gmpz_init_set (in /usr/lib64/libgmp.so.3.5.0) ==12209== by 0x4B20C9: gfc_copy_shape (expr.c:373) ==12209== by 0x4B2353: gfc_copy_expr (expr.c:556) ==12209== by 0x4B5567: simplify_parameter_variable (expr.c:1633) ==12209== by 0x4B5317: gfc_simplify_expr (expr.c:1744) ==12209== by 0x4B5236: gfc_simplify_expr (expr.c:882) ==12209== by 0x4FE188: resolve_operator (resolve.c:3584) ==12209== by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== by 0x4FE04B: resolve_operator (resolve.c:3307) ==12209== by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== ==12209== 158 bytes in 1 blocks are definitely lost in loss record 276 of 352 ==12209== at 0x4A04481: calloc (vg_replace_malloc.c:418) ==12209== by 0xC8DE48: xcalloc (xmalloc.c:162) ==12209== by 0x625854: init_emit (emit-rtl.c:5566) ==12209== by 0x6B9EC7: prepare_function_start (function.c:4183) ==12209== by 0x6B9F68: init_function_start (function.c:4231) ==12209== by 0x5373CD: trans_function_start (trans-decl.c:1928) ==12209== by 0x540976: gfc_generate_function_code (trans-decl.c:4292) ==12209== by 0x4ECC9B: gfc_parse_file (parse.c:4226) ==12209== by 0x521BF7: gfc_be_parse_file (f95-lang.c:239) ==12209== by 0x80A2BB: do_compile (toplev.c:1053) ==12209== by 0x80A9FD: toplev_main (toplev.c:2459) ==12209== by 0x36EE81EB1C: (below main) (libc-start.c:226) ==12209== ==12209== 158 bytes in 1 blocks are definitely lost in loss record 277 of 352 ==12209== at 0x4A04481: calloc (vg_replace_malloc.c:418) ==12209== by 0xC8DE48: xcalloc (xmalloc.c:162) ==12209== by 0x625854: init_emit (emit-rtl.c:5566) ==12209== by 0x6B9EC7: prepare_function_start (function.c:4183) ==12209== by 0x6B9F68: init_function_start (function.c:4231) ==12209== by 0x54122C: gfc_generate_function_code (trans-decl.c:4105) ==12209== by 0x4ECC9B: gfc_parse_file (parse.c:4226) ==12209== by 0x521BF7: gfc_be_parse_file (f95-lang.c:239) ==12209== by 0x80A2BB: do_compile (toplev.c:1053) ==12209== by 0x80A9FD: toplev_main (toplev.c:2459) ==12209== by 0x36EE81EB1C: (below main) (libc-start.c:226) ==12209==
Assuming PR37173 is correct, isn't this example invalid anyway (as already noted by Tobias in #4)? Instead, it should probably be written as: CHARACTER (kind=4,len=*) MY_STRING4(1:3) PARAMETER ( MY_STRING4 = (/ 4_"A" , 4_"B", 4_"C" /) ) END
Author: fxcoudert Date: Sat Oct 4 10:18:07 2014 New Revision: 215887 URL: https://gcc.gnu.org/viewcvs?rev=215887&root=gcc&view=rev Log: PR fortran/36534 * resolve.c (resolve_fl_procedure): Clean up obsolescence warning. * gfortran.dg/widechar_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/widechar_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk