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.