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]

[PATCH] Java: array alignment patch.


This patch fixes a problem with the alignment of the data member of
the array objects:

  http://gcc.gnu.org/ml/java/2001-02/threads.html#00099

It's been tested on x86/PPC/Alpha Linux. I'm checking this in.  Let me
know if it breaks something.

Special thanks to Jeff Sturm for investigating this and for his
extensive testing support on alpha!

./A

2001-02-05  Jeff Sturm  <jeff.sturm@commerceone.com>
	    Alexandre Petit-Bianco  <apbianco@cygnus.com>

	* typeck.c (build_prim_array_type): Added leading comment.
	(build_java_array_type): Moved locals out of
	block. Always create the `data' field, fixed alignment to match
	C++.

Index: typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/typeck.c,v
retrieving revision 1.36
diff -u -p -r1.36 typeck.c
--- typeck.c	2001/02/04 22:44:06	1.36
+++ typeck.c	2001/02/07 01:26:16
@@ -359,6 +359,11 @@ java_array_type_length (array_type)
   return -1;
 }
 
+/* An array of unknown length will be ultimately given an length of
+   -2, so that we can still have `length' producing a negative value
+   even if found. This was part of an optimization amaing at removing
+   `length' from static arrays. We could restore it, FIXME.  */
+
 tree
 build_prim_array_type (element_type, length)
      tree element_type;
@@ -378,7 +383,7 @@ build_java_array_type (element_type, len
      tree element_type;
      HOST_WIDE_INT length;
 {
-  tree sig, t, fld;
+  tree sig, t, fld, atype, arfld;
   char buf[12];
   tree elsig = build_java_signature (element_type);
   tree el_name = element_type;
@@ -416,39 +421,11 @@ build_java_array_type (element_type, len
   FIELD_PUBLIC (fld) = 1;
   FIELD_FINAL (fld) = 1;
 
-  if (length >= 0)
-    {
-      tree atype = build_prim_array_type (element_type, length);
-      tree arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
-      
-      DECL_CONTEXT (arfld) = t;
-      TREE_CHAIN (fld) = arfld;
-
-      /* We need to force the data field to begin at an alignment at
-       least equal to the biggest alignment in an object type node
-       in order to be compatible with the way that JArray is defined
-       in CNI.  However, we can't exceed BIGGEST_FIELD_ALIGNMENT. */
-      {
-      unsigned desired_align = TYPE_ALIGN (object_type_node);
-      desired_align = MAX (desired_align, TYPE_ALIGN (element_type));
-#ifdef BIGGEST_FIELD_ALIGNMENT
-      desired_align = MIN (desired_align, 
-                           (unsigned) BIGGEST_FIELD_ALIGNMENT);
-#endif
-#ifdef ADJUST_FIELD_ALIGN
-      desired_align = ADJUST_FIELD_ALIGN (fld, desired_align);
-#endif
-      DECL_ALIGN (arfld) = desired_align;
-      }
-    }
-  else
-    {
-      unsigned desired_align = TYPE_ALIGN (element_type);
-#ifdef BIGGEST_FIELD_ALIGNMENT
-      desired_align = MIN (desired_align, (unsigned) BIGGEST_FIELD_ALIGNMENT);
-#endif
-      TYPE_ALIGN (t) = desired_align;
-    }
+  atype = build_prim_array_type (element_type, length);
+  arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
+  DECL_CONTEXT (arfld) = t;
+  TREE_CHAIN (fld) = arfld;
+  DECL_ALIGN (arfld) = TYPE_ALIGN (element_type);
 
   /* We could layout_class, but that loads java.lang.Object prematurely.
    * This is called by the parser, and it is a bad idea to do load_class

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