| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(Plus a bonus item: one Android-written test under luni.)
|
|\
| |
| |
| |
| | |
Conflicts:
libcore/JavaLibrary.mk
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I started off with a mission to remove uses of dalvik.annotation.* (stuff
like @TestTargetNew and other useless junk that just makes it harder to
stay in sync with upstream). I wrote a script to go through tests showing
me the diff between what we have and what upstream has, thinking that in
cases where upstream has also added tests, I may as well pull them in at
the same time...
...but I didn't realize how close we were to having dx fill its 1.5GiB heap.
After trying various alternatives, I decided to bite the bullet and break
core-tests up into one .jar per module. This adds parallelism back into this,
the slowest part of our build. (I can do even better, but I'll do that in a
separate patch, preferably after we've merged recent changes from master.)
Only a couple of dependencies were problematic: the worthless TestSuiteFactory
which already contained a comment suggesting we get rid of it, and the fact
that some tests -- most notably the concurrent ones -- also contained main
methods that started the JUnit tty-based TestRunner.
(In the long run, we want to be running the harmony tests directly from a
pristine "svn co" of upstream, using DalvikRunner. But this will be a big
help in the meantime, and starts the work of getting our current copy of
the tests into a state where we can start to extract any meaningful
changes/additions we've made.)
|
|/
|
|
|
|
|
|
|
| |
The >= versus > bug was fixed in openssl somewhere between .98g and .98k (we
don't have _all_ versions conveniently lying around), and our removal of
the disjunct was irrelevant. Call the now-correct upstream code instead of
manually inlining and hacking it.
Also rename BN_lshift to BN_shift, since it handles both left and right shifts.
|
|
|
|
|
|
|
|
|
|
| |
jessewilson reverted an upstream change (https://issues.apache.org/jira/browse/HARMONY-4623)
that caused an RI incompatibility. Although it seems like the RI behavior is
wrong, the poor design of BigDecimal.equals (which checks both value *and*
scale) probably means we should remain compatible.
This patch changes the test expectation to match the RI's behavior and adds
a comment in both the code and its test explaining that this is deliberate.
|
|
|
|
| |
Plus other jtreg test scrubbing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
valgrind complains about invalid 4-byte reads, caused by "case 8" in the
BNInterface.c function I'm removing here, which assumed that if we're checking
whether a BIGNUM fits in 8 bytes, it must require more than 4 bytes (and so
accessing d[1] is acceptable).
We can implement this in Java using the existing BigInteger.bitLength
method (which may call down to native code, but that native code looks okay).
Also remove a related commented-out method.
Bugs: 2223213, 2225642
|
|
|
|
| |
See bug 2183132.
|
|\
| |
| |
| |
| |
| |
| | |
Merge commit '4b30428421d4ad93d9e6fc34bc0190a5097dc4a6'
* commit '4b30428421d4ad93d9e6fc34bc0190a5097dc4a6':
Fix BigInteger math bugs.
|
| |
| |
| |
| |
| | |
This initializes the internal representation before doing left shifts.
I'd originally missed this in the first Harmony update; change 20002.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeBN_bn2twosComp doesn't do what it claims to: it's an exact copy of
NativeBN_BN_bn2bin (observe which OpenSSL BN_ function it calls!), and -- from
the OpenSSL documentation -- that function "converts the absolute value of [its
argument] into big-endian form".
OpenSSL doesn't actually sport any appropriate function to call here, but
luckily this code isn't called anywhere, and so can be removed.
(BigInteger.toByteArray -- the most likely caller of this code -- seems to
do the right thing, using Java code to make a big-endian two's-complement
byte[]. Likewise, the conversion from a big-endian two's-complement byte[]
for the corresponding BigInteger constructor looks right too, using native
code to twiddle the bits itself.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notable changes:
- lots of trailing whitespace and "@since Android 1.0" tags removed
- shiftLeft(1) replaced with shiftLeftOneBit(). That case can be optimized
more aggressively than the general case. The new method exists in BigInteger
and calls through to a new method in BitLevel in the same way as Harmony.
This is a squashed commit of the following:
commit 3f071487bdb8fff0b4a71ce0219ee7e1e16369fb
Merge: 4fda354 10640b6
Author: Jesse Wilson <jessewilson@google.com>
Date: Tue Aug 4 12:02:25 2009 -0700
Merge branch 'math_772995' into math_dalvik
Conflicts:
libcore/math/.classpath
libcore/math/build.xml
libcore/math/src/main/java/java/math/BigDecimal.java
libcore/math/src/main/java/java/math/BigInteger.java
libcore/math/src/main/java/java/math/Division.java
libcore/math/src/main/java/java/math/Elementary.java
libcore/math/src/main/java/java/math/Logical.java
libcore/math/src/main/java/java/math/MathContext.java
libcore/math/src/main/java/java/math/Multiplication.java
libcore/math/src/main/java/java/math/Primality.java
libcore/math/src/main/java/java/math/RoundingMode.java
libcore/math/src/test/java/tests/api/java/math/BigDecimalTest.java
libcore/math/src/test/java/tests/api/java/math/BigIntegerTest.java
commit 4fda354bd7d2c0ee918c86fa89852310cc8f2af7
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:12:27 2009 -0700
Dalvik Math
commit 10640b6b254200f1c89553072e50137f6ad46c84
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:11:07 2009 -0700
Math 772995
commit 15302f6d09b3547f1018e3d228f233f8f72c7de9
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:08:19 2009 -0700
Math 527399
|
|
|
|
|
|
|
|
| |
don't work properly in the CTS environment for
some reason.
BUG=1285921
Automated import of CL 148447
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|