class.c, [...]: Fix comment typos.

	* class.c, gjavah.c, lang.c: Fix comment typos.
	* gcj.texi: Fix typos.

From-SVN: r79744

gcc/java/ChangeLog

+2004-03-20  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* class.c, gjavah.c, lang.c: Fix comment typos.
+	* gcj.texi: Fix typos.
+
 2004-03-19  Per Bothner  <per@bothner.com>
 
 	* gcj.texi (Code Generation):  Document new flags and assert defaults.

gcc/java/class.c

@@ -201,7 +201,7 @@ add_assume_compiled (const char *ident, int excludep)
   add_class_flag (&assume_compiled_tree, ident, excludep);
 }
 
-/* The default value returned by enable_asserstions. */
+/* The default value returned by enable_assertions. */
 
 #define DEFAULT_ENABLE_ASSERT (flag_emit_class_files || optimize == 0)
 
@@ -240,7 +240,7 @@ assume_compiled (const char *ident)
 bool
 enable_assertions (tree klass)
 {
-  /* Check if command-line specifies whether we should check asserrtions. */
+  /* Check if command-line specifies whether we should check assertions. */
 
   if (klass != NULL_TREE && DECL_NAME (klass) && enable_assert_tree != NULL)
     {

gcc/java/gcj.texi

@@ -435,7 +435,7 @@ optimization off, regardless of the optimization level in use.
 @item --disable-assertions[=@var{class-or-package}]
 Don't include code for checking assertions in the compiled code.
 If @code{=@var{class-or-package}} is missing disables assertion code
-generation for all classes, unless overrideen by a more
+generation for all classes, unless overridden by a more
 specific @code{--enable-assertions} flag.
 If @var{class-or-package} is a class name, only disables generating
 assertion checks within the named class or its inner classes.
@@ -443,7 +443,7 @@ If @var{class-or-package} is a package name, disables generating
 assertion checks within the named package or a subpackage.
 
 By default, assertions are enabled when generating class files
-or when not optimizaing, and disabled when generating optimized binaries.
+or when not optimizing, and disabled when generating optimized binaries.
 
 @item --enable-assertions[=@var{class-or-package}]
 Generates code to check assertions.  The option is perhaps misnamed,

gcc/java/gjavah.c

@@ -1416,7 +1416,7 @@ print_c_decl (FILE* stream, JCF* jcf, int name_index, int signature_index,
 	}
 
       /* Force the alignment of the first data member.  This is
-	 because the "new" C++ ABI changed the alignemnt of non-POD
+	 because the "new" C++ ABI changed the alignment of non-POD
 	 classes.  gcj, however, still uses the "old" alignment.  */
       if (is_first_data_member && ! (flags & ACC_STATIC) && ! is_method)
 	{

gcc/java/lang.c

@@ -949,7 +949,7 @@ merge_init_test_initialization (void **entry, void *x)
   
   However, what if the method that is suppoed to do the initialization
   is itself inlined in the caller?  When expanding the called method
-  we'll assume that the class initalization has already been done,
+  we'll assume that the class initialization has already been done,
   because the DECL_INITIAL of the init_test_decl is set.
   
   To fix this we remove the DECL_INITIAL (in the caller scope) of all