When a file contains a number of repeated '0x00' or '0xff'
bytes, the block header is copied from a precomputed header,
which only worked for Little-Endian systems.
Fixes#311.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
igzip/igzip_icf_body.c:7:1: warning: type of 'gen_icf_map_lh1' does not match original declaration [-Wlto-type-mismatch]
7 | gen_icf_map_lh1(struct isal_zstream *, struct deflate_icf *, uint32_t);
| ^
igzip/igzip_base_aliases.c:177:1: note: return value type mismatch
177 | gen_icf_map_lh1(struct isal_zstream *stream, struct deflate_icf *matches_icf_lookup,
| ^
igzip/igzip_base_aliases.c:177:1: note: type 'void' should match type 'uint64_t'
igzip/igzip_base_aliases.c:177:1: note: 'gen_icf_map_lh1' was previously declared here
igzip/igzip_base_aliases.c:177:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used
igzip/igzip_icf_body.c:9:1: warning: type of 'set_long_icf_fg' does not match original declaration [-Wlto-type-mismatch]
9 | set_long_icf_fg(uint8_t *, uint64_t, uint64_t, struct deflate_icf *);
| ^
igzip/igzip_base_aliases.c:170:1: note: type mismatch in parameter 2
170 | set_long_icf_fg(uint8_t *next_in, uint8_t *end_in, struct deflate_icf *match_lookup,
| ^
igzip/igzip_base_aliases.c:170:1: note: 'set_long_icf_fg' was previously declared here
igzip/igzip_base_aliases.c:170:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used
igzip/igzip_base_aliases.c:62:1: warning: type of 'set_long_icf_fg_base' does not match original declaration [-Wlto-type-mismatch]
62 | set_long_icf_fg_base(uint8_t *next_in, uint8_t *end_in, struct deflate_icf *match_lookup,
| ^
igzip/igzip_icf_body.c:34:1: note: type mismatch in parameter 2
34 | set_long_icf_fg_base(uint8_t *next_in, uint64_t processed, uint64_t input_size,
| ^
igzip/igzip_icf_body.c:34:1: note: 'set_long_icf_fg_base' was previously declared here
igzip/igzip_icf_body.c:34:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used
igzip/igzip_base_aliases.c:54:1: warning: type of 'adler32_base' does not match original declaration [-Wlto-type-mismatch]
54 | adler32_base(uint32_t init, const unsigned char *buf, uint64_t len);
| ^
igzip/adler32_base.c:34:1: note: type mismatch in parameter 3
34 | adler32_base(uint32_t adler32, uint8_t *start, uint32_t length)
| ^
igzip/adler32_base.c:34:1: note: type 'uint32_t' should match type 'uint64_t'
igzip/adler32_base.c:34:1: note: 'adler32_base' was previously declared here
igzip/adler32_base.c:34:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used
Signed-off-by: Mattias Ellert <mattias.ellert@physics.uu.se>
The soname is equal to current minus age.
In version 2.31.0 current is 2 and age is set to 0.
In version 2.31.1 current is 2 and age is set to 1.
This means the soname goes backwards from 2 to 1.
The full library version changes from 2.0.31 to 1.1.31
The soname should not go backwards, so this soname change looks like a
mistake that should be reverted.
The current, revision, age for a library should change in one of three ways:
1) increase current by one, reset revision and age to 0.
2) increase current by one, reset revision to 0 and increase age by 1.
3) increase revision by 1, retain the values of current and age.
1) is for non-backward compatible changes to the library (changes or
removals to the old ABI). Soname changes and applications using the
library must be recompiled.
2) is for when there are ABI additions to the library, but no ABI
changes or removals. Application compiled against the old version of
the library don't need to be recompiled, and the soname (current minus
age) does not change.
3) is for minor updates with no ABI additions, changes or removals.
The major, minor, patch version of the software project should not be
used as current, revision, age for the library. Especially true for
using the patch version as age, because that means the soname goes
backwards for patch releases as happened here.
Signed-off-by: Mattias Ellert <mattias.ellert@physics.uu.se>
Compilation with clang gave warnings as per below.
Arm64 is has a width of 64 bit and these warnings came up.
In file included from igzip/aarch64/igzip_multibinary_aarch64_dispatcher.c:29:
./include/aarch64_multibinary.h:338:35: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
asm("mrs %0, MIDR_EL1 " : "=r" (id));
^
./include/aarch64_multibinary.h:338:12: note: use constraint modifier "w"
asm("mrs %0, MIDR_EL1 " : "=r" (id));
^~
%w0
1 warning generated.
In file included from mem/aarch64/mem_aarch64_dispatcher.c:29:
./include/aarch64_multibinary.h:338:35: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
asm("mrs %0, MIDR_EL1 " : "=r" (id));
^
./include/aarch64_multibinary.h:338:12: note: use constraint modifier "w"
asm("mrs %0, MIDR_EL1 " : "=r" (id));
^~
%w0
1 warning generated.
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
There are quite a few spelling mistakes and typos in comments and
user facing message literal strings as found using codespell. Fix
these.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
gf_vect_mul_base is expected to work for all buffer sizes.
However, this function is checking for size alignment to 32 bytes,
to follow the other gf_vect_mul implementations.
Therefore, another implementation for this function is included
inside ppc64le folder to be used by the encoding functions.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
