[Bug fortran/45077] New: ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[Bug fortran/45077] New: ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

+++ This bug was initially created as a clone of Bug #40011 +++

The program of PR 40011 comment 47 (attachment 18427)  works -fno-whole-file
but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021.


-- 
           Summary: ICE with -fwhole-file in fold_convert_loc, at fold-
                    const.c:2021
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 40011


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

[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2010-07-27 09:49 -------
Reduced test case:
!------------------------------------------------------------------
module iso_red
  type, public :: varying_string
     character(LEN=1), dimension(:), allocatable :: chars
  end type varying_string
end module iso_red

module ifiles
  use iso_red, string_t => varying_string
contains
  function line_get_string_advance (line) result (string)
    type(string_t) :: string
    character :: line
  end function line_get_string_advance
end module ifiles

module syntax_rules
  use iso_red, string_t => varying_string
  use ifiles, only: line_get_string_advance
contains
  subroutine syntax_init_from_ifile ()
    type(string_t) :: string
       string = line_get_string_advance ("")
  end subroutine syntax_init_from_ifile
end module syntax_rules
end
!------------------------------------------------------------------

The ICE occurs for:
  gfc_trans_assignment (trans-expr.c:5561)
    gfc_trans_assignment_1 (trans-expr.c:5419)
      gfc_trans_scalar_assign (trans-expr.c:4909)
       fold_convert_loc (fold-const.c:2021)

The fancy_abort occurs because TREE_CODE (type) is gcc_unreachable, type is the
second argument. The call is:
      gfc_add_modify (&block, lse->expr,
                           fold_convert (TREE_TYPE (lse->expr), rse->expr));
Namely "TREE_TYPE (lse->expr)" as "location_t" is added as first via #define.

Hereby LHS is variable "string" and RHS is function "line_get_string_advance".
Both have the same type: expr1->ts.u.derived->name == "varying_string" and
point to the _same_ expr2->ts.u.derived->backend_decl.

However, the data type looks different at TREE_TYPE, i.e.
    lse->expr.common.type != rse->expr.common.type

My working theory is that one generates a different back-end decl for
type(varying_string) and type(string_t).

However, ts.u.derived->backend_decl is the same - and as
ts.type.derived->components{,->ts.u.cl}->backend_decl is the same, I am not
sure whether this theory is correct.


-- 


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

[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-07-28 07:43 -------
Patch. Note: It still fails if one moves "module iso_red" into a separate file.
Cf. PR 44945. The reason is that then "gsym" will come up as NULL and every
module user uses a different decl.

Index: trans-types.c
===================================================================
--- trans-types.c       (revision 162617)
+++ trans-types.c       (working copy)
@@ -1994,6 +1994,8 @@ gfc_get_derived_type (gfc_symbol * deriv
          gfc_symbol *s;
          s = NULL;
          gfc_find_symbol (derived->name, gsym->ns, 0, &s);
+          if (s && !s->backend_decl)
+            s->backend_decl = gfc_get_derived_type (s);
          if (s && s->backend_decl)
            {
              gfc_copy_dt_decls_ifequal (s, derived, true);


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-28 07:43:55
               date|                            |


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

[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-07-28 08:44 -------
Subject: Bug 45077

Author: burnus
Date: Wed Jul 28 08:44:29 2010
New Revision: 162619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162619
Log:
2010-07-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45077
        * trans-types.c (gfc_get_derived_type): Fix DT declaration
        from modules for whole-file mode.

2010-07-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45077
        * gfortran.dg/whole_file_24.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_24.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-07-28 08:47 -------
Fixed for the unmodified example in comment 1 - and also for PR 40011 comment
47.

However, the following remains to be done: It still fails if one moves "module
iso_red" into a separate file (cf. PR 44945). The reason is that then "gsym"
will come up as NULL and every
module user uses a different decl.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|burnus at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2010-07-29 17:00 -------
(In reply to comment #4)
> Fixed for the unmodified example in comment 1 - and also for PR 40011 comment
> 47.
> 
> However, the following remains to be done: It still fails if one moves "module
> iso_red" into a separate file (cf. PR 44945). The reason is that then "gsym"
> will come up as NULL and every
> module user uses a different decl.

The challenge to handle truly external procedures correctly is to use - if
possible - the correct interface. For EXTERNAL this is not quite possible - but
one should try to merge the different declarations while one parses the file,
e.g. when one encounters "EXTERNAL" one generates a GSYM - which later gets
updated with the interface (if present somewhere), by procedure usage ("call"),
or by the actual external procedure if it comes later in the file. At the same
time, a consistency check for type and arguments can be done.


-- 


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