[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

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

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-20 16:36:55 UTC ---
Fixed on trunk.

Thanks for the report.

Paul

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

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-20 16:23:57 UTC ---
Author: pault
Date: Sun Feb 20 16:23:50 2011
New Revision: 170337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170337
Log:
2011-02-20  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/45077
    PR fortran/44945
    * trans-types.c (gfc_get_derived_type): Remove code that looks
    for decls in gsym and add call to gfc_get_module_backend_decl.
    * trans.h : Add prototype for gfc_get_module_backend_decl.
    * trans-decl.c (gfc_get_module_backend_decl): New function.
    (gfc_get_symbol_decl): Call it.

2011-02-20  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/45077
    PR fortran/44945
    * gfortran.dg/whole_file_28.f90 : New test.
    * gfortran.dg/whole_file_29.f90 : New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_28.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_29.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 15:08:18 UTC ---
Although pr40440 has been marked as fixed the original test in comment #0
(i.e., using a non included iso_varying_string.mod) is still yielding an ICE
with trunk:

pr40440.f90: In function 'syntax_init_from_ifile':
pr40440.f90:719:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2028

This ICE is fixed by the patch in comment #6. All the other problems reported
in this pr and in pr44945 have been silenced on trunk for
x86_64-apple-darwin10, making difficult to say that the patches have fixed
them. Otherwise the patch works as expected without regressions.

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

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-20 11:39:56 UTC ---
(In reply to comment #6)
> Fixes the problem.  Bootstraps and regtests OK.

I glanced at it and it looks OK.

> dg-additional-sources is not sufficient is it?  That is does it generate:
> gfortran source1.f90 source2.f90
> or 
> gfortran -c source1.f90 -o source1.o
> gfortran source2.f90 source1.0

I think both are effectively the same: For "gfortran source2.f90 source1.f90",
the driver (gfortran) calls twice the compiler (f951) which generates in
/tmp/... the assembler files, the driver then calls the assembler (as) twice
and, finally, the linker (collect1). The driver only combined the two source
files when "-combined" is used, though I think that feature was not available
for Fortran and will not work with dg-additional-sources.
That can be seen when running "gfortran -v source2.f90 source1.f90" by looking
for the f951 lines.

Note: The file specified by dg-additional-sources is compiled after the one
which has the "dg-additional-sources" specified. Additionally, one needs to
provide a fall-back compilation as the second file is also compiled
independently.
See pr37287-1.f90 and pr37287-2.F90 as an example.

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

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |pault at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-20 11:21:14 UTC ---
Created attachment 23410
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23410
fix for the version of the problem in comments #4 and #5

Fixes the problem.  Bootstraps and regtests OK.

How do I write a testcase to exercise this?

dg-additional-sources is not sufficient is it?  That is does it generate:

gfortran source1.f90 source2.f90

or 

gfortran -c source1.f90 -o source1.o
gfortran source2.f90 source1.0

??

The second is what is needed.

Paul