Libjava failures status
Bryce McKinlay
bryce@waitaki.otago.ac.nz
Tue Mar 12 03:12:00 GMT 2002
Jan Hubicka wrote:
>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.
>
It would be nice if we could avoid pessimising this too much. eg given:
a = foo.a;
b = foo.b;
Then obviously the second load from foo can not trap. I assume that
would allow for larger BBs and that is good for optimization.
>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).
>
Correct. However, this is only an issue on x86, and perhaps other CPUs
which trap integer divide-by-zero. On all other platforms we just have
to do an explicit check for a zero divisor.
>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.
>
Yes, I just checked and it still fails with tonight's mainline.
Curiously, it is failing even without -O.
regards
Bryce.
More information about the Java
mailing list