clang-10 throws the following error:
In file included from external/org_brotli/c/enc/bit_cost.c:9:
external/org_brotli/c/enc/./bit_cost.h:48:16: error: implicit conversion
from 'size_t' (aka 'unsigned long') to 'double' may lose precision
[-Werror,-Wimplicit-int-float-conversion]
if (retval < sum) {
~ ^~~
1 error generated.
Make the conversion explicit.
* IMPORTANT: decoder: fix potential overflow when input chunk is >2GiB
* simplify max Huffman table size calculation
* eliminate symbol duplicates (static arrays in .h files)
* minor combing in research/ code
Otherwise libraries will not be found at runtime when installing to a
path not included in the default runtime linker's path with programs
linking brotli configured via pkg-config.
- fix formatting
- fix type conversion
- fix no-op arithmetic with null-pointer
- improve performance of hash_longest_match64
- go: detect read after close
- java decoder: support compound dictionary
- remove executable flag on non-scripts
Add an option to avoid building shared libraries (for building with EMCC)
Drive-by:
* maven: ramp up java level to minimal required
* travis: replace deprecated clang-5.0 with clang-7
* maven: fallback to jdk10 to void javadoc bug
* Verbose CLI + start pulling "Shared-Brotli"
* vesbose CLI output; fix#666
* pull `SHIFT` transforms; currently this is semantically dead code;
later it will be used by "Shared-Brotli"
Make sure the travis CI aarch32 bot tests NEON, and also that running
CROSS_COMPILE=arm-linux-gnueabihf make enables the use of NEON to
accelerate the back-reference copying.
The macro that checks for NEON support should be __ARM_NEON, not
__ARM_NEON__. [1]
AArch64 compilers define __ARM_NEON but not __ARM_NEON__.
AArch32 compilers currently seem to define both, but could be within their
rights to drop __ARM_NEON__ in future versions.
This change moves the check into the common/platform.h file, checks for
both forms, and sets BROTLI_TARGET_NEON if NEON support is available.
[1] Section 6.5.4 of the ARM C Language Extensions.
(At the time of writing, the latest version was Release 2.1.)
* platform: add macro for using the 'aligned' attribute
* decode: add accessor macros for HuffmanCode fields
Adds a constructor function for building HuffmanCode values
so they can be accessed quickly on different architectures.
Also adds macros for marking a HuffmanCode table pointer
that can be accessed quickly (BROTLI_HC_MARK_TABLE_FOR_FAST_LOAD),
adjusting the index into that table (BROTLI_HC_ADJUST_TABLE_INDEX),
and getting the .bits or .value fields out of the table at the
current index (BROTLI_HC_GET_BITS/VALUE).
For example, assuming |table| contains a HuffmanCode pointer:
BROTLI_HC_MARK_TABLE_FOR_FAST_LOAD(table);
BROTLI_HC_ADJUST_TABLE_INDEX(table, index_into_table);
*bits = BROTLI_HC_GET_BITS(table);
*value = BROTLI_HC_GET_VALUE(table);
BROTLI_HC_ADJUST_TABLE_INDEX(table, offset);
*bits2 = BROTLI_HC_GET_BITS(table);
*value2 = BROTLI_HC_GET_VALUE(table);
All uses of the HuffmanCode have been updated appropriately.
* decode: add alternative accessors for HuffmanCode on Arm AArch32
* build: add cross-compilation support to make
Set CROSS_COMPILE when running make to use the selected cross
compilation toolchain, such as arm-linux-gnueabihf, or
aarch64-linux-gnu.
Testing requires the presence of qemu - 'qemu-$(ARCH)' will be executed,
where ARCH is the first part of the toolchain triplet.
* build: add cross-compilation support to cmake
If C_COMPILER/CXX_COMPILER/CC/CXX are found to have cross-compilation
triplets in front of the compiler, then qemu will be used to execute the
tests.
* CI: add arm-linux-gnueabihf-gcc builder to Travis
The version of qemu available in Ubuntu trusty (as provided by Travis)
appears to have a bug in qemu-aarch64, which leads to the compatibility
tests failing on some inputs, erroneously rejecting the input as
corrupt.
Once Travis supports xenial, we could add an aarch64-gnu-linux-gcc
builder as well.
* CI: propagate cmake errors out of .travis.sh
Seems like even if cmake fails, the error isn't picked up by Travis.
