Bug 38672 - [4.3 Regression] ICE during build with versions 4.3.2 and 4.4-20081226
Summary: [4.3 Regression] ICE during build with versions 4.3.2 and 4.4-20081226
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P4 normal
Target Milestone: 4.3.4
Assignee: Thomas Koenig
URL: http://gcc.gnu.org/ml/fortran/2009-01...
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-12-30 13:07 UTC by Tom Browder
Modified: 2009-01-24 21:50 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.4.0
Known to fail: 4.3.3
Last reconfirmed: 2009-01-01 20:06:07


Attachments
Output from gfortan -v (778 bytes, text/plain)
2008-12-30 13:09 UTC, Tom Browder
Details
Archive with files to demonstrate the bug. (1.81 KB, application/octet-stream)
2008-12-30 13:11 UTC, Tom Browder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Browder 2008-12-30 13:07:01 UTC
The attached archive (Makefile, 2 source files, and output from gfortran -v) yields an ICE during build with versions 4.3.2 and 4.4-20081226 (but not version 4.1.2 20070925 (Red Hat 4.1.2-27)).
Comment 1 Tom Browder 2008-12-30 13:09:19 UTC
Created attachment 17014 [details]
Output from gfortan -v
Comment 2 Tom Browder 2008-12-30 13:11:14 UTC
Created attachment 17015 [details]
Archive with files to demonstrate the bug.

The Makefile has a variable at the top to pick specific (or not) versions of gfortran.
Comment 3 Tobias Burnus 2008-12-30 16:50:22 UTC
Works with 4.2.1 (x86_64-suse-linux). Valgrind shows:

==27337== Invalid read of size 1
==27337==    at 0x4752E2: resolve_symbol (resolve.c:9311)
==27337==    by 0x482726: traverse_ns (symbol.c:3127)
==27337==    by 0x482715: traverse_ns (symbol.c:3124)
==27337==    by 0x482715: traverse_ns (symbol.c:3124)
==27337==    by 0x470A3F: resolve_types (resolve.c:10428)

That seems to be:
  if (sym->ts.type == BT_DERIVED
        && sym->ts.derived->attr.use_assoc
        && sym->ns->proc_name->attr.flavor == FL_MODULE)

The problem is that for sym->name == "pdm_bps":
(gdb) p sym->ts.type
$3 = BT_DERIVED
(gdb) p sym->ts.derived->attr.use_assoc
$4 = 1
(gdb) p sym->ns->proc_name
$5 = (struct gfc_symbol *) 0x0

Thus there is no surprise that sym->ns->proc_name->attr.flavor gives an ICE.

Note:

(gdb) p sym->attr.flavor
$7 = FL_VARIABLE


The line was added as part of the following commit:

r133488 | pault | 2008-03-24 20:11:24 +0100 (Mon, 24. Mar 2008) | 21 lines

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.
Comment 4 Andrew Pinski 2009-01-01 05:20:59 UTC
Here is a reduced testcase:
    MODULE globals
      TYPE :: type1
      END TYPE type1
      TYPE (type1) :: pdm_bps
    END module globals
      BLOCK DATA
      use globals
      END

Comment 5 Thomas Koenig 2009-01-01 18:38:08 UTC
This is looking promising (and passes regression-test), and I think
that this does the right thing (the symbol in question doesn't need
to be a procedure, correct?)

Paul, could you maybe comment?

$ svn diff
Index: resolve.c
===================================================================
--- resolve.c   (revision 142857)
+++ resolve.c   (working copy)
@@ -9263,6 +9263,7 @@ resolve_symbol (gfc_symbol *sym)
      module function and is not PRIVATE.  */
   if (sym->ts.type == BT_DERIVED
        && sym->ts.derived->attr.use_assoc
+       && sym->ns->proc_name
        && sym->ns->proc_name->attr.flavor == FL_MODULE)
     {
       gfc_symbol *ds;
Comment 6 Jakub Jelinek 2009-01-01 19:44:00 UTC
Looks very similar to PR37829.
Comment 7 Thomas Koenig 2009-01-05 10:43:50 UTC
Subject: Bug 38672

Author: tkoenig
Date: Mon Jan  5 10:43:39 2009
New Revision: 143074

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143074
Log:
2009-01-05  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/38672
	* trans-types.c (gfc_get_derived_type):  Check for the
	presence of derived->ns->proc_name before
	accessing derived->ns->proc_name->attr.flavor .
	* resolve.c (resolve_symbol):  Likewise.

2009-01-05  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/38672
	* gfortran.dg/host_assoc_blockdata_1.f90:  New test.
	* gfortran.dg/host_assoc_blockdata_2.f90:  New test.


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

Comment 8 Thomas Koenig 2009-01-05 10:46:32 UTC
Fixed on trunk, will wait for a few days before committing
to 4.3.
Comment 9 Richard Biener 2009-01-24 10:21:09 UTC
GCC 4.3.3 is being released, adjusting target milestone.
Comment 10 Thomas Koenig 2009-01-24 21:49:41 UTC
Subject: Bug 38672

Author: tkoenig
Date: Sat Jan 24 21:49:28 2009
New Revision: 143655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143655
Log:
2009-01-24  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/38672
	* resolve.c (resolve_symbol):  Check for the
	presence of derived->ns->proc_name before
	accessing derived->ns->proc_name->attr.flavor .

2009-01-24  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/38672
	* gfortran.dg/host_assoc_blockdata_1.f90:  New test.
	* gfortran.dg/host_assoc_blockdata_2.f90:  New test.


Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_blockdata_1.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_blockdata_2.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

Comment 11 Thomas Koenig 2009-01-24 21:50:21 UTC
Fixed on 4.3 as well.

Closing.