Re: Libjava failures status

[Jan Hubicka <jh at suse dot cz>]

> >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 
The reordering problems are, I hope, fixed by the series of patches I sent
last week.

Now, at least according to the internal check, we maitain the BB boundaries
consistent and we should reorder over them.  I plan to add symetrical check
verifying that we do not discover trapping instruciton in the middle of basic
block - so far I am just checking that if there is EH edge there is trapping
instruction just before it.  We may avoid trap in my sanity check if pass
does wrong transformation and then uses purge_dead_edges that will kill
the EH edge completely forgetting about the exception.

The removal of code is other interesting issue I wasn't aware of.
It means that if I write something like division by zero with unused
result, Java specification says we must throw? (unlike C where such
cases are usually undefined).

We are definitly invalid from this point of view and fixing it would
be major task I guess as in many places we convert trapping instructions
to non-trapping without any such checking.

> 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 

Sure, but we should be consistent according to the standards.
Thats actually why I was asking if there are testcases - this is typical example
where if we get 10% of exception sites misscompiled, we are still unlikely
to hit problems in real code.
> 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.

Is this one still failing? If so, i would like to take a look at this.
Even moving the instruction should not change exception handler it reaches
as we no longer keep exceptions as intervals, rather store the information
to each insn.

Thanks for clarification,  I guess I should browse trought the Java standard
to understand the issue better.
Honza
> 
> regards
> 
> Bryce.
>