Libjava failures status

[Bryce McKinlay]

Jan Hubicka wrote:

>>Yes, Java has always used them - its required by the language - and in 
>>general they do seem to work. I have noticed some test case strangeness 
>>(libjava Array_3) where an instruction that could throw (due to non-call 
>>exceptions) was removed incorrectly by the optimizer on PowerPC but not 
>>on i686.
>>
>
>Are the exceptions actually throwed?  What I am affraid of is that we
>just manage to lose track of the possibly trapping instructions during
>the optimization progress. Last about 10 bugfixes has been to these areas
>and I really don't know how big the problem is, but basically every pass
>appears to do something wrong to non-call exceptions.
>

The only danger, afaik, is if an instruction that can throw (pointer 
dereference or integer divide) would be seen to have no other 
side-effects and is removed or reordered across other instructions that 
do have side effects. But, I think its fairly unlikely that real code 
would care since the NullPointerException/ArithmeticException are there 
to catch programming errors and its bad style to use them for actual 
flow control. When such exceptions occur the side effects of other 
nearby instructions would almost certainly be ignored by the users code.

>So it would be nice to have some testcase that actually trhrows the
>exceptions and check that everything is going well.
>

There are various libjava test cases which do test this. Array_3 is one 
that I have seen failing, on PowerPC: a dereference with no side effects 
is apparantly moved outside of its try {} block and the exception lands 
in the wrong handler. But if the case is changed so that the result is 
saved somewhere then it works fine.

regards

Bryce.