This program gives an ICE when compiled with gfortran 4.4 trunk: FUNCTION myfortran_error () USE ISO_C_BINDING IMPLICIT NONE CHARACTER(LEN=5) :: myfortran_error CHARACTER(KIND=C_CHAR, LEN=5), POINTER :: chararr TYPE(C_PTR) :: c_str c_str = C_NULL_PTR CALL C_F_POINTER (c_str, chararr) myfortran_error(1:1) = chararr(1) END FUNCTION myfortran_error bash-3.2# gfortran-dev reduced.f03 reduced.f03: In function 'myfortran_error': reduced.f03:8: internal compiler error: in fold_convert, at fold-const.c:2649 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. gfortran 4.3 compiles it but fails with an undefined reference to `chararr_'. Actually I'm not proficient with C binding, so I would not bet the code above is legal or doing "correct" things with the pointers... However, it should not ICE.
Confirmed. myfortran_error(1:1) = chararr(1) gfc_match_rvalue can't find a proper substring reference for chararr. Thus as chararr's flavor is FL_UNKNOWN, gfc_match_rvalue tries to guess its type and after some tests defaults to a function call. Then, as chararr is registered as a function it fails in the middle end when trying to convert a pointer type to a function type. This is not a regression as the link error from 4.3 tells us (I think) that chararr went through the middle-end as a function. I think the correct syntax is: myfortran_error(1:1) = chararr(1:1)
This is still happening with current gfortran trunk, though the ICE is now in [/tmp]# gfortran-dev test.f90 test.f90: In function 'myfortran_error': test.f90:8:0: internal compiler error: in fold_convert_loc, at fold-const.c:2789 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. I will work on this.
As another note, I already did the mistake of indexing a string as str(n) instead of str(n:n) for single characters multiple times; and IIRC there's not much useful a diagnostic in any case, so maybe I can improve there as well.
$ gfortran-4.5 pr38849.f90 pr38849.f90: In function 'MAIN__': pr38849.f90:9:0: internal compiler error: in gimplify_expr, at gimplify.c:7346 $ gfortran-svn pr38849.f90 gimplification failed: chararr <addr_expr 0xb77a43b8 type <pointer_type 0xb77a3c00 type <function_type 0xb77a3ba0 type <void_type 0xb7729780 void> QI size <integer_cst 0xb77190f0 constant 8> unit size <integer_cst 0xb7719108 constant 1> align 8 symtab 0 alias set -1 canonical type 0xb77a3ba0 arg-types <tree_list 0xb779ec60 value <reference_type 0xb77a3b40> chain <tree_list 0xb779ec78 value <integer_type 0xb77292a0 integer(kind=4)> chain <tree_list 0xb779ec90 value <void_type 0xb7729780 void>>>> pointer_to_this <pointer_type 0xb77a3c00>> unsigned SI size <integer_cst 0xb7719240 constant 32> unit size <integer_cst 0xb7719078 constant 4> align 32 symtab 0 alias set -1 canonical type 0xb77a3c00> constant arg 0 <function_decl 0xb77a2c00 chararr type <function_type 0xb77a3ba0> public external QI file pr38849.f90 line 5 col 0 align 8 chain <function_decl 0xb77a2b00 MAIN__ type <function_type 0xb774d060> used static QI file pr38849.f90 line 2 col 0 align 8 initial <block 0xb7727104> result <result_decl 0xb7722348 D.1499> (mem:QI (symbol_ref:SI ("MAIN__") [flags 0x3] <function_decl 0xb77a2b00 MAIN__>) [0 S1 A8]) struct-function 0xb772239c chain <function_decl 0xb77a2a80 _gfortran_st_set_nml_var_dim>>>> pr38849.f90: In function 'MAIN__': pr38849.f90:9:0: internal compiler error: gimplification failed $ gfortran-svn -v gcc version 4.6.0 20100518 (experimental) (GCC)
With gfortran 4.6.3 and later I get: myfortran_error(1:1) = chararr(1) 1 Error: The pointer object 'chararr' at (1) must have an explicit function interface or be declared as array The error message is not extremely clear about what is wrong, but at least there is no ICE any more. Is it worth to improve the error message, or should we just close this one?
(In reply to comment #5) > The error message is not extremely clear about what is wrong, but at least > there is no ICE any more. Is it worth to improve the error message, or should > we just close this one? Let's close.