The following code produces the error "internal compiler error: in fold_convert, at fold-const.c:2626" when compiled with GCC trunk rev. 128037: module A type A_type real comp end type end module A module B contains function initA() use A implicit none type(A_type):: initA initA%comp=1.0 end function end module B program C use B use A implicit none type(A_type):: A_var A_var = initA() end program C The crucial part here are the USE statements in program C. The error only pops up when they appear as listed above. Exchanging them to use A use B makes the error vanish. The error is also killed by A_var = initA() It happens for GCC 4.3.0 (trunk) as well as 4.1.3 and 4.2.1. The target system is i686-pc-linux-gnu.
> The error is also killed by > > A_var = initA() Sorry. The error is killed by *removing* this line.
Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() from gfc_trans_scalar_assign(): (gdb) bt #0 fancy_abort (file=0xb322f0 "../../gcc-svn/trunk/gcc/fold-const.c", line=2626, function=0xb321d2 "fold_convert") at ../../gcc-svn/trunk/gcc/diagnostic.c:654 #1 0x00000000005c6eec in fold_convert (type=0x2aaaae2d0340, arg=0x2aaaadff54b0) at ../../gcc-svn/trunk/gcc/fold-const.c:2626 #2 0x0000000000492f0e in gfc_trans_scalar_assign (lse=0x7fff3ff81120, rse=0x7fff3ff810d0, ts= {type = BT_DERIVED, kind = 0, derived = 0xf97230, cl = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN}, l_is_temp=0 '\0', r_is_var=0 '\0') at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:3609 #3 0x0000000000496ca5 in gfc_trans_assignment_1 (expr1=0xf97130, expr2=0xf97700, init_flag=0 '\0') at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4011 #4 0x0000000000496dbc in gfc_trans_assignment (expr1=0xf97130, expr2=0xf97700, init_flag=210 '�') at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4152 #5 0x000000000047b116 in gfc_trans_code (code=0xf986c0) at ../../gcc-svn/trunk/gcc/fortran/trans.c:970 #6 0x000000000048fc73 in gfc_generate_function_code (ns=0xf960e0) at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:3258 (gdb) up #1 0x00000000005c6eec in fold_convert (type=0x2aaaae2d0340, arg=0x2aaaadff54b0) at ../../gcc-svn/trunk/gcc/fold-const.c:2626 2626 gcc_unreachable (); (gdb) p debug_tree (type) <record_type 0x2aaaae2d0340 a_type SF size <integer_cst 0x2aaaadff1a50 type <integer_type 0x2aaaadffe0d0 bit_size_type> constant invariant 32> unit size <integer_cst 0x2aaaadff16c0 type <integer_type 0x2aaaadffe000> constant invariant 4> align 32 symtab 0 alias set -1 canonical type 0x2aaaae2d0340 fields <field_decl 0x2aaaae2cbe70 comp type <real_type 0x2aaaae00a5b0 real4 SF size <integer_cst 0x2aaaadff1a50 32> unit size <integer_cst 0x2aaaadff16c0 4> align 32 symtab 0 alias set -1 canonical type 0x2aaaae00a5b0 precision 32 pointer_to_this <pointer_type 0x2aaaae00a820>> SF file c.f90 line 1 size <integer_cst 0x2aaaadff1a50 32> unit size <integer_cst 0x2aaaadff16c0 4> align 32 offset_align 128 offset <integer_cst 0x2aaaadff16f0 constant invariant 0> bit offset <integer_cst 0x2aaaadff1f30 constant invariant 0> context <record_type 0x2aaaae2d0340 a_type>> chain <type_decl 0x2aaaae2d0410 D.1372>>
(In reply to comment #2) > Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() I've also started seeing this while working on my "create only one decl per procedure" patch. I wasn't aware that it can also be triggered on mainline. In my case, we come there because two different decls are created for one given type. Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type), add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both RECORD_TYPEs have the same size, and that their fields correspond one-to-one, and then create a VIEW_CONVERT_EXPR? Do you think it would be worth having or would that hurt the middle-end in any way?
(In reply to comment #3) > Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type), > add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both > RECORD_TYPEs have the same size, and that their fields correspond one-to-one, > and then create a VIEW_CONVERT_EXPR? Do you think it would be worth having or > would that hurt the middle-end in any way? This is not exactly the part of gcc I'm familiar with (and c never generates RECORD_TYPEs), but I think that this problem should be fixed in fortran/trans-expr.c. At least according to the comment above fold_convert(), this conversion should be handled in front-end convert function. The "patch" below (similar to your proposal, with minimal checking) "works" in the sense that the compilation doesn't break, and generated code doesn't create a black hole at runtime, but I have no idea if it is correct (fortran) transformation. Also, we will break here if sizes are not equal. Index: fold-const.c =================================================================== --- fold-const.c (revision 128092) +++ fold-const.c (working copy) @@ -2616,6 +2616,10 @@ || TREE_CODE (orig) == VECTOR_TYPE); return fold_build1 (VIEW_CONVERT_EXPR, type, arg); + case RECORD_TYPE: + gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig))); + return fold_build1 (VIEW_CONVERT_EXPR, type, arg); + case VOID_TYPE: tem = fold_ignored_result (arg); if (TREE_CODE (tem) == GIMPLE_MODIFY_STMT) >
Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE statements On 4 Sep 2007 19:03:39 -0000, ubizjak at gmail dot com <gcc-bugzilla@gcc.gnu.org> wrote: > and c never generates RECORD_TYPEs Yes it does. Structs in C are done as RECORD_TYPEs. This code is just plainly wrong really. fold_convert should not handle RECORD_TYPEs. And if does, it is not going to help with optimizations anyways. The Fortran front-end has to better keep track of modules and types inside modules to get this correct. Thanks, Andrew Pinski
(In reply to comment #5) > Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE statements > > On 4 Sep 2007 19:03:39 -0000, ubizjak at gmail dot com > <gcc-bugzilla@gcc.gnu.org> wrote: > > and c never generates RECORD_TYPEs > > Yes it does. Structs in C are done as RECORD_TYPEs. > > This code is just plainly wrong really. fold_convert should not > handle RECORD_TYPEs. And if does, it is not going to help with > optimizations anyways. The Fortran front-end has to better keep track > of modules and types inside modules to get this correct. > > Thanks, > Andrew Pinski > Andrew, I agree with you wholeheartedly on this. I missed this PR somehow. I thought that I had cleared up all these nasties with derived types and modules. I'll take a look tonight. Cheers Paul
Subject: Bug 33295 Author: pault Date: Mon Mar 24 19:11:24 2008 New Revision: 133488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133488 Log: 2008-03-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: trunk/gcc/testsuite/gfortran.dg/module_function_type_1.f90 trunk/gcc/testsuite/gfortran.dg/null_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 33295 Author: pault Date: Mon Mar 24 21:10:36 2008 New Revision: 133490 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133490 Log: 2008-03-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_function_type_1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/null_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
Fixed on trumk and 4.3. Thanks for the report. Paul