Java: array clean up and store check optimization

[Bryce McKinlay]

Alexandre Petit-Bianco wrote:

>>bootstrapped and regtested on i686 and PowerPC Linux. OK to commit?
>>
>
>This is a really interesting patch, thanks a lot for writing it. My
>only concerns is that in the past we had problems with recognizing
>arrays constructs in certain situations, with or without bound checks,
>when generating bytecodes or going natives, etc...
>
>Some of these are in our test suite. My question is, where you able to
>run regressions, testing the combinations of the new flags?
>

The test suite runs without regressions in the default mode on i686 
linux. The --no-store-check and --no-bounds-check will of course cause 
failures for test cases which rely on proper JLS compliance, but I've 
tested the 3 combinations of these flags on quite a few apps and it they 
seem to work fine. I did find a couple of obscure array bugs while 
testing (these are in the test suite as ArrayStore.java and 
ArrayStore2.java), but they existed before this patch.

I have tested byte->native compilation too, and the patch should not 
effect source->byte at all.

>>Index: lang-options.h
>>===================================================================
>>RCS file: /cvs/gcc/gcc/gcc/java/lang-options.h,v
>>retrieving revision 1.28
>>diff -c -r1.28 lang-options.h
>>*** lang-options.h	2001/08/09 04:19:12	1.28
>>--- lang-options.h	2002/02/20 00:58:06
>>...
>>***************
>>*** 54,56 ****
>>--- 56,60 ----
>>      N_("Always check for non gcj generated classes archives") },
>>    { "-fno-optimize-static-class-initialization",
>>      N_("Never optimize static class initialization code") },
>>+   { "-findirect-dispatch",
>>+     N_("Use offset tables for virtual method calls") },
>>
>
>Does this hunk belong to this patch?
>

Not really, this is a missing help string from a previous patch.

regards

Bryce.