This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Libjava failures status

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]