[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-24 19:12 --- Subject: Bug 33295 Author: pault Date: Mon Mar 24 19:11:24 2008 New Revision: 133488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133488 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-24 21:11 --- Subject: Bug 33295 Author: pault Date: Mon Mar 24 21:10:36 2008 New Revision: 133490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133490 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-25 05:34 --- Fixed on trumk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-21 08:02 --- (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 -, ubizjak at gmail dot com [EMAIL PROTECTED] 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 -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-03 20:07:11 |2008-03-21 08:02:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-04 10:39 --- (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? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #4 from ubizjak at gmail dot com 2007-09-04 19:03 --- (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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #5 from pinskia at gmail dot com 2007-09-04 19:08 --- Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE statements On 4 Sep 2007 19:03:39 -, ubizjak at gmail dot com [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #1 from jaydub66 at gmail dot com 2007-09-03 18:05 --- The error is also killed by A_var = initA() Sorry. The error is killed by *removing* this line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #2 from ubizjak at gmail dot com 2007-09-03 20:07 ---
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 0x005c6eec in fold_convert (type=0x2e2d0340,
arg=0x2dff54b0)
at ../../gcc-svn/trunk/gcc/fold-const.c:2626
#2 0x00492f0e 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 0x00496ca5 in gfc_trans_assignment_1 (expr1=0xf97130,
expr2=0xf97700, init_flag=0 '\0')
at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4011
#4 0x00496dbc in gfc_trans_assignment (expr1=0xf97130, expr2=0xf97700,
init_flag=210 '#65533;')
at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4152
#5 0x0047b116 in gfc_trans_code (code=0xf986c0) at
../../gcc-svn/trunk/gcc/fortran/trans.c:970
#6 0x0048fc73 in gfc_generate_function_code (ns=0xf960e0)
at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:3258
(gdb) up
#1 0x005c6eec in fold_convert (type=0x2e2d0340,
arg=0x2dff54b0)
at ../../gcc-svn/trunk/gcc/fold-const.c:2626
2626 gcc_unreachable ();
(gdb) p debug_tree (type)
record_type 0x2e2d0340 a_type SF
size integer_cst 0x2dff1a50 type integer_type 0x2dffe0d0
bit_size_type constant invariant 32
unit size integer_cst 0x2dff16c0 type integer_type 0x2dffe000
constant invariant 4
align 32 symtab 0 alias set -1 canonical type 0x2e2d0340
fields field_decl 0x2e2cbe70 comp
type real_type 0x2e00a5b0 real4 SF size integer_cst
0x2dff1a50 32 unit size integer_cst 0x2dff16c0 4
align 32 symtab 0 alias set -1 canonical type 0x2e00a5b0
precision 32
pointer_to_this pointer_type 0x2e00a820
SF file c.f90 line 1 size integer_cst 0x2dff1a50 32 unit size
integer_cst 0x2dff16c0 4
align 32 offset_align 128
offset integer_cst 0x2dff16f0 constant invariant 0
bit offset integer_cst 0x2dff1f30 constant invariant 0 context
record_type 0x2e2d0340 a_type
chain type_decl 0x2e2d0410 D.1372
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-03 20:07:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
