This is the mail archive of the
mailing list for the GCC project.
Re: [c++,committed] Revert patch for PR/c++2294
Eric Botcazou wrote:
You mean the patch does not break libjava on 3.3.3?
Sorry, I mis-read the PR number, my CVS checkout for the 3.3 branch has
2003-11-14 Bernardo Innocenti <email@example.com>
Backport from 3.4-branch.
2003-06-25 Giovanni Bajo <firstname.lastname@example.org>
* pt.c (unify): Add support for PTRMEM_CST and
as the last ChangeLog entry, so I didn't test the patch for PR2294.
As a matter of fact, Giovanni fixed both PR2094 and PR2294 :-)
Ok then, I've not yet reverted it, so it can stay.
A quick test to determine whether libjava is broken is to run the C++
testsuite. If you see hundreds of failures, then libjava is very likely
IIRC, Giovanni ran the g++.dg part of the testsuite just before
sending me his patch.
Is it possible that libjava has been using some weird C++ construct
that was accepted by mistake before PR2294?
The offending code looks like this:
1105 _Jv_divI (jint dividend, jint divisor)
1107 if (__builtin_expect (divisor == 0, false))
1109 java::lang::ArithmeticException *arithexception
1110 = new java::lang::ArithmeticException (JvNewStringLatin1 ("/ by zero"));
1111 throw arithexception;
1114 if (dividend == (jint) 0x80000000L && divisor == -1)
1115 return dividend;
1117 return dividend / divisor;
I can see nothing strange at lines 1110 and 1111. The problem may lie
in ArithmeticException, but the Java source looks fine.
It would be interesting to see what the generated ArithmeticException.h
looks like. I usually perform native builds with Java disabled, so I
can't see it right now.
I'm currently running a full rebuild with the latest combined tree...
I'll let you know.
// Bernardo Innocenti - Develer S.r.l., R&D dept.