[Bug fortran/33295] New: ICE in fold_const.c (fold_convert) when reordering USE statements

[Bug fortran/33295] New: ICE in fold_const.c (fold_convert) when reordering USE statements

[jaydub66 at gmail dot com]

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.


-- 
           Summary: ICE in fold_const.c (fold_convert) when reordering USE
                    statements
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jaydub66 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295

[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements

[jaydub66 at gmail dot com]

------- 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

[ubizjak at gmail dot com]

------- 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  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>>


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-03 20:07:11
               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

[fxcoudert at gcc dot gnu dot org]

------- 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

[ubizjak at gmail dot com]

------- 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

[pinskia at gmail dot com]

------- 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 -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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295

[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements

[pault at gcc dot gnu dot org]

------- 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 -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


-- 

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

[pault at gcc dot gnu dot org]

------- 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=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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295

[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements

[pault at gcc dot gnu dot org]

------- 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=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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295

[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements

[pault at gcc dot gnu dot org]

------- 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