Recent versions of Cygwin's GCC no longer support the -mno-cygwin flag
(compilation works, but linking fails). However, Cygwin now includes
mingw64-i686-gcc, mingw64-x86_64-gcc, and related packages, so we use
those compilers instead. This has the added benefit that we can build
native x86_64 binaries on Cygwin now.
This will break the build for old Cygwin installs, so it will be
necessary to upgrade Cygwin and install the aforementioned packages to
build Avian going forward.
This was causing 8-byte SSE-to-SSE moves involving registers
xmm8-xmm15 to be misencoded on x86_64, leading to incorrect code
generation in methods with lots of local variables of type double.
We were not always placing parameters in the correct stack positions
in the PowerPC implementations of dynamicCall and vmNativeCall. In
particular, the first stack slot used to hold a parameter depends on
the sizes and types of the preceding parameters which are passed in
registers.
Added JavaVM to include path. Also allow dynamically building with
different SDK versions through the OSX_SDK_VERSION and OSX_SDK_SYSROOT
environment variables (these default to the previosly hardcoded value of
10.4 and 10.4u respectively).
Previously, Deflater.deflate would pass Z_SYNC_FLUSH to zlib
unconditionally, which caused the output to be enormous when setInput
was called repeatedly with very small input buffers. In order to
allow zlib to buffer output and thereby maximize compression, we must
use Z_NO_FLUSH until Deflater.finish is called, at which point we
switch to Z_FINISH. We also modify DeflaterOutputStream.close to call
Deflater.finish and write any remaining output to the wrapped stream.
We can only omit the jump past a constant pool if it's placed at the
end of a method, which is only true if the pool belongs to the last
block of that method and that block is not so large that the pool must
be placed inside the block instead of after it.
The previous code did not take into account any padding embedded in a
basic block due to inline jump tables, which led to invalid code
generation in large methods
OpenJDK's compile.c and Avian's compile.cpp were both being compiled
to compile.o, which led to a conflict when building libavian.a. We
now append "-openjdk" to the object file name for OpenJDK code to
avoid such conflicts.
If we fail to resolve a given class (e.g. due to ProGuard obfuscating
or eliminating it), just move on to the next one rather than return
immediately. Otherwise, we may miss intercepting methods of classes
we can resolve.
