Latest on PPC

Tue Mar 20 12:54:00 GMT 2001

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> The particular call to fold() comes from gcc/java/typeck.c:convert():
Tom> 	return fold (convert_to_integer (type, expr));
Tom> I'm going to try only calling fold() when not emitting bytecode. I
Tom> have no idea whether that will help. It sure seems like a hack. But
Tom> eventually I think we'll want a Java-specific fold() anyway.
This was a miserable failure. Other parts of the front end rely on
fold() to fold constants.
It turns out that these parts of fold() are controlled by the
optimizatio level.
So here is a hideous patch which has the desired effect.
This patch is really horrible. For one thing if you use
`-fno-emit-class-files', the wrong thing will happen (why you would
want to do this, I don't know). For another thing, it is obviously
just a hack.
However, maybe it is the only reasonable way to fix the problem, for
now anyway -- I think the real fix is to write our own fold() and
relegate use of the generic fold() to a phase after bytecode
generation. That is more work than should go into 3.0 though, and
anyway I definitely don't have the time.
If anybody can think of a better fix, I'd like to know.
2001年03月20日 Tom Tromey <tromey@redhat.com>
	* lang.c (process_option_with_no): Disable optimization if
	bytecode generation is enabled.
Tom
Index: lang.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/lang.c,v
retrieving revision 1.59.4.1
diff -u -r1.59.4.1 lang.c

--- lang.c	2001年03月17日 21:53:11	1.59.4.1
+++ lang.c	2001年03月20日 20:47:37
@@ -203,23 +203,37 @@
 int table_size;
 {
 int j;
+ int v = 0;
 
 for (j = 0; j < table_size; j++)
 {
 if (!strcmp (p, table[j].string))
 	{
 	 *table[j].variable = table[j].on_value;
-	 return 1;
+	 v = 1;
+	 break;
 	}
 if (p[0] == 'n' && p[1] == 'o' && p[2] == '-'
 	 && ! strcmp (p+3, table[j].string))
 	{
 	 *table[j].variable = ! table[j].on_value;
-	 return 1;
+	 v = 1;
+	 break;
 	}
 }
 
- return 0;
+ /* FIXME: when compiling to bytecode, some optimizations introduced
+ by fold() cause the bytecode generator to become confused. So if
+ we see -C then we disable optimizations. This is a temporary,
+ ugly, hack. However it is "ok" because we don't currently try to
+ generate efficient bytecode anyway. */
+ if (flag_emit_class_files)
+ {
+ extern int optimize;
+ optimize = 0;
+ }
+
+ return v;
 }
 
 /*
