/src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In function 'option_stopwatch_s':^M /src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:63: error: statement types mismatch^M (*D.1170)[S.73D.1171]{lb: 0 sz: _a.72D.1168} = (*D.1173)[S.74D.1174];^M ^M charD.14[1:_aD.1051]^M charD.14[1:6]^M /src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:63: internal compiler error: verify_stmts failed^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (test for excess errors)
Andrew, How, when and where does this happen, please? Paul
This happens when the first patch in PR 22368 is added.
Here's a detailed analysis of the current testsuite failures with Andrew's patches from PR22368 (all patches applied) on i686-linux. First testcase (from actual_array_constructor_1.f90): subroutine bar(a) character(len=*) :: a call foo((/ a, 'g' /)) end The error message issued is actual_array_constructor_1.f90: In function ‘bar’: actual_array_constructor_1.f90:3: error: statement types mismatch (*D.941)[S.9D.942]{lb: 0 sz: _a.8D.939} = D.946; charD.14[1:_aD.902] charD.14[1:1] actual_array_constructor_1.f90:3: internal compiler error: verify_stmts failed Second testcase: interface pure function double (string) character (len = *), intent (in) :: string character (len = len (string)) :: double end function double end interface print *, f5("foo") contains function f5 (string) character (len = *) :: string character (len = len (double (string))) :: f5 f5 = '' end function f5 end returns (at -O1): char_result_1.f90: In function ‘MAIN__’: char_result_1.f90:1: error: statement types mismatch D.949_16 = stringD.939_11; charD.14[1:3] & charD.14[1:_stringD.907] & char_result_1.f90:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Third testcase: real c if (loc(c) == 0) call abort end produces: loc_2.f90: In function ‘MAIN__’: loc_2.f90:2: error: types mismatch in comparsion <unnamed type> int4D.2 D.903 == 0; loc_2.f90:2: internal compiler error: verify_stmts failed Fourth testcase: call foo("g") contains subroutine foo (s) character(*), optional :: s if (present(s)) call abort end subroutine end produces missing_optional_dummy_1.f90: In function ‘MAIN__’: missing_optional_dummy_1.f90:1: error: types mismatch in comparsion charD.14[1:_sD.904] * charD.14[1:1] * sD.913_1 != 0B; missing_optional_dummy_1.f90:1: internal compiler error: verify_stmts failed
(In reply to comment #3) > real c > if (loc(c) == 0) call abort > end This one has been fixed on mainline.
Behavior is different with today's mainline on i386-darwin. Without optimization the first one gives an error further down the line, and the other three pass: 1.f90:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:4671 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. With optimization, the first three pass, and the fourth gives the same error that FX has seen.
I don't understand why it fails in the fourth case. The comparison it seems to complain about is generated via return build2 (NE_EXPR, boolean_type_node, decl, fold_convert (TREE_TYPE (decl), null_pointer_node)); (trans-expr.c:141) which looks like it gets the types right. Replacing the call to fold_convert with an equivalent call to build_int_cst doesn't help either, BTW.
(In reply to comment #6) Tobi, > (trans-expr.c:141) which looks like it gets the types right. Replacing the > call to fold_convert with an equivalent call to build_int_cst doesn't help > either, BTW. Does casting the decl to be of the same type as null_pointer_node help? ie; decl = fold_convert (TREE_TYPE (null_pointer_node), decl); return build2 (NE_EXPR, boolean_type_node, decl, null_pointer_node); Paul
None of the testcases in comment #3 fail on the mainline configured with --enable-checking=yes,types. So either this bug is fixed or the patches from Andrew did some slightly different checking. Or both ;)
Type-checking is now in mainline, and PR31608 is tracking the last remaining failure exposed in the testsuite. Closing this PR.