* class.c, gjavah.c, lang.c: Fix comment typos.
* gcj.texi: Fix typos.
From-SVN: r79744
+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.
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)
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)
{
@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.
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,
}
/* 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)
{
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