This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[incremental] Patch: FYI: handle VLAs in c_type_hash


I'm checking this in on the incremental-compiler branch.

On the branch, c_type_hash can see a type with a VLA, which it doesn't
know how to handle, causing an ICE.  This happens because I removed an
'if (num_in_fnames == 1)' from c_common_get_alias_set, but it seemed
best to just add a case for this in c_type_hash.

I'm undecided as to whether I should restore that condition in
c_common_get_alias_set.  I think I may end up with a normalization
pass that runs just before gimplification (but after the server has
forked for code generation), so that we can strip out
VIEW_CONVERT_EXPRs and smash types and decls... and if we do this then
we won't need the special type merging code used by --combine.

Meanwhile, this fixes some test suite failures.  The ICE is
reproducible on the trunk using --combine; I filed this as PR 34457.

Tom

ChangeLog:
2007-12-14  Tom Tromey  <tromey@redhat.com>

	* c-common.c (c_type_hash): Handle VLAs.

Index: c-common.c
===================================================================
--- c-common.c	(revision 130607)
+++ c-common.c	(working copy)
@@ -3035,7 +3035,11 @@
     }
   for (; t2; t2 = TREE_CHAIN (t2))
     i++;
-  size = TREE_INT_CST_LOW (TYPE_SIZE (t));
+  /* We might have a VLA here.  */
+  if (TREE_CODE (TYPE_SIZE (t)) != INTEGER_CST)
+    size = 0;
+  else
+    size = TREE_INT_CST_LOW (TYPE_SIZE (t));
   return ((size << 24) | (i << shift));
 }
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]