Re: Ongoing bootstrap failures on ppc64 since 2007-07-02

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

Dorit sent me a copy of the libgfortran/config.log on
her failing system.  In looking through the log, I've
found (note, I've paths to ABC, XYZ for shortness):


configure:11335: checking if ABC/./gcc/gfortran -BABC/./gcc/ -BXYZ/bin/
  -BXYZ/lib/ -isystem XYZ/include -isystem XYZ/sys-include supports -c
  -o file.o
configure:11382: result: no
configure:11412: checking whether the ABC/./gcc/gfortran -BABC/./gcc/
  -BXYZ/bin/ -BXYZ/lib/ -isystem XYZ/include -isystem XYZ/sys-include
  linker (ABC/./gcc/collect-ld -m elf64ppc) supports shared libraries
configure:12487: result: yes
configure:12624: checking dynamic linker characteristics
configure:13000: ABC/./gcc/gfortran -BABC/./gcc/ -BXYZ/bin/ -BXYZ/lib/ -isystem XYZ/include -isystem XYZ/sys-include -o conftest   -Wl,-rpath -Wl,/foo  conftest.f  >&5
conftest.f: In function 'MAIN__':
conftest.f:1: internal compiler error: tree check: expected parm_decl,
  have function_decl in set_tree_decl_type_code, at fortran/trans-decl.c:2869
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
configure:13006: $? = 1
configure: failed program was:
|       program main
| 
|       end
configure:13243: result: GNU/Linux ld.so
configure:13287: checking how to hardcode library paths into programs
configure:13312: result: immediate

configure:13356: checking whether the GNU Fortran compiler is working
configure:13370: ABC/./gcc/gfortran -BABC/./gcc/ -BXYZ/bin/ -BXYZ/lib/
  -isystem XYZ/include -isystem XYZ/sys-include -c   conftest.f >&5
conftest.f: In function 'MAIN__':
conftest.f:2: internal compiler error: tree check: expected parm_decl,
    have function_decl in set_tree_decl_type_code, at fortran/trans-decl.c:2869
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
configure:13376: $? = 1
configure: failed program was:
| 
|       program foo
|       real, parameter :: bar = sin (12.34 / 2.5)
|       end program foo
configure:13397: result: no
configure:13399: error: GNU Fortran is not working; please report
   a bug in http://gcc.gnu.org/bugzilla, attaching ABC/XYZ/libgfortran/\
    config.log

Neither of these codes should result in a code path to 
set_tree_decl_type_code() in fortran/trans-decl.c.   The only
use of this function is in this section of code:

  if (sym->attr.dummy == 1)
    {
      /* The sym->backend_decl can be NULL if this is one of the
        intrinsic types, such as the symbol of type c_ptr for the
        c_f_pointer function, so don't set up the tree code for it.  */
      if (sym->attr.value == 1 && sym->backend_decl != NULL)
       set_tree_decl_type_code (sym);
    }

The newly built gfortran must be stomping on memory.  I've found that
attached patch allows gfortran to still function.  Could someone who
sees this problem try bootstrapping gfortran with the patch?

-- 
Steve

Index: trans-decl.c
===================================================================
--- trans-decl.c	(revision 126447)
+++ trans-decl.c	(working copy)
@@ -2850,7 +2850,7 @@
    approach the C compiler takes (or it appears to be this way).  When
    the middle-end is given the typed node rather than the POINTER_TYPE
    node, it knows to pass the value.  */
-
+#if 0
 static void
 set_tree_decl_type_code (gfc_symbol *sym)
 {
@@ -2873,6 +2873,7 @@
 
    return;
 }
+#endif
 
 
 /* Drill down through expressions for the array specification bounds and
@@ -3024,14 +3025,14 @@
 	}
     }
 
-  if (sym->attr.dummy == 1)
-    {
-      /* The sym->backend_decl can be NULL if this is one of the
-	 intrinsic types, such as the symbol of type c_ptr for the
-	 c_f_pointer function, so don't set up the tree code for it.  */
-      if (sym->attr.value == 1 && sym->backend_decl != NULL)
-	set_tree_decl_type_code (sym);
-    }
+#if 0
+  /* The sym->backend_decl can be NULL if this is one of the intrinsic types,
+     such as the symbol of type c_ptr for the c_f_pointer function, so don't
+     set up the tree code for it.  */
+  if (sym->attr.flavor != FL_PROCEDURE && sym->attr.dummy == 1
+      && sym->attr.value == 1 && sym->backend_decl != NULL)
+    set_tree_decl_type_code (sym);
+#endif
 
   /* Make sure we convert the types of the derived types from iso_c_binding
      into (void *).  */