search for: bitmath

Hello, While building from git, I'm getting the following failure (help please): CC ogg_mapping.lo CCLD libFLAC.la Creating library file: .libs/libFLAC.dll.a .libs/bitreader.o: In function `FLAC__clz_soft_uint32': ./include/private/bitmath.h:46: multiple definition of `_FLAC__clz_soft_uint32' .libs/bitmath.o:./include/private/bitmath.h:46: first defined here .libs/fixed.o: In function `FLAC__clz_soft_uint32': ./include/private/bitmath.h:46: multiple definition of `_FLAC__clz_soft_uint32' .libs/bitmath.o:./include/private/...

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c b/src/libFLAC/bitmath.c inde...

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)) /* This w...

There is a function FLAC__clz_soft_uint32 in bitmath.h: static inline unsigned int FLAC__clz_soft_uint32(unsigned int word) { static const unsigned char byte_to_unary_table[] = { 8, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, .................................... 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }; retur...

...: Entering directory `/c/src/flac/src/libFLAC' if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DFLaC__INLINE=inline -DNDEBUG -I../.. -I./include -I../../include -fno-common -I/usr/local/include -O3 -funroll-loops -finline-functions -Wall -W -Winline -g -O2 -MT bitmath.lo -MD -MP -MF ".deps/bitmath.Tpo" \ -c -o bitmath.lo `test -f 'bitmath.c' || echo './'`bitmath.c; \ then mv -f ".deps/bitmath.Tpo" ".deps/bitmath.Plo"; \ else rm -f ".deps/bitmath.Tpo"; exit 1; \ fi ../../lib...

FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL -> CC0 change: http://lis...

...iph.org/pipermail/opus/2014-April/002592.html "proper architecture-specific MSVC definitions, _M_IX86 and _M_X64" So this patch changes _WIN64 to _M_X64 (the corresponding code enables _BitScanReverse64) -------------- next part -------------- A non-text attachment was scrubbed... Name: bitmath.patch Type: application/octet-stream Size: 938 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140409/77feee25/attachment.obj

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inlin...

...a pointer to FLAC__uint64 > (8-byte int). IMHO it's a bug I would not call that a bug, just a result of trying to write cross platform code and relying on functions that are not specified by any standard. > 2. FLAC__clz_uint32() returns the result of BitScanReverse() XOR 31. > FLAC__bitmath_ilog2() returns 31-FLAC__clz_uint32() == 31-(BSR^31). > > As 0<=BSR<=31 so 31-(BSR^31) == BSR. But I don't think that compilers > are so smart that can optimize this expression. So it is better to change > FLAC__bitmath_ilog2() so it simply calls BitScanReverse() when possibl...

...ame for 64-bit version). "sizeof(FLAC__uint32) * CHAR_BIT" must be 32, or the code won't work. So it's simpler to use "31 - FLAC__clz_uint32(v)" or even better, "FLAC__clz_uint32(v) ^ 31". Why XORing is better: gcc implements __builtin_clz as bsr^31, so FLAC__bitmath_ilog2() now calculates 31 - (bsr^31). GCC is unable to simplify it to just bsr. But it can do it for (bsr^31)^31. 5) The patch adds FLAC__U64L() for a big constant. -------------- next part -------------- A non-text attachment was scrubbed... Name: 2_bitmath_h.patch Type: application/octet-stream...

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m; m=(_v>0xFFFFFFFFU)<<5; v=(FLAC__uint32)(_v>>m);...

...nation of this patch. 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is a pointer to unsigned long (4-byte int). However _BitScanReverse64() is called with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug and this patch changes the type of idx variable inside FLAC__bitmath_ilog2_wide() from FLAC__uint64 to unsigned long. The type of idx variable inside FLAC__bitmath_ilog2() was also changed (from FLAC__uint32 to unsigned long), for symmetry. 2. FLAC__clz_uint32() returns the result of BitScanReverse() XOR 31. FLAC__bitmath_ilog2() returns 31-FLAC__clz_uint32() =...

...ools-mingw-w64/sandbox/mingw-w64-x86_64/x86_64-w64-mingw32/include -O3 -funroll-loops -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Winline -Wdeclaration-after-statement -D_FORTIFY_SOURCE=2 -msse2 -MT bitmath.lo -MD -MP -MF .deps/bitmath.Tpo -c bitmath.c -DDLL_EXPORT -DPIC -o .libs/bitmath.o In file included from ../../include/share/compat.h:150:0, from ./include/private/bitmath.h:39, from bitmath.c:37: ../../include/share/win_utf8_io.h:54:43: warning: 'struct __st...

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif...

Hi, I was wondering how much worse FLAC performance would be if it was compiled integer-only, but while trying to do so (by adding #define FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got this error > ./include/private/bitmath.h:134:5: error: operator '&&' has no left > operand bitmath.h:134 is the following line > #if && defined(__GNUC__) && (__GNUC__ >= 4 || (__GNUC__ == 3 && > __GNUC_MINOR__ >= 4)) I really wonder why anyone would have left it like this. Mayb...

Hi all, I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if this is the right place to submit patches, but someone suggested this on the apparently dead SourceForge patch tracker. The first two are quite straight forward: - The ICL patch fixes a typo in bitmath.h and adds FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c. - The Ogg patch replaces the check for FLAC_API_SUPPORTS_OGG_FLAC in stream_decoder.c with FLAC__HAS_OGG to fix compilation with Ogg support. The _lseeki64 patch probably is a little more controversial. The prob...

...man --infodir=/home/avuton/src/mpd-release-utils/build-dir/info --disable-dependency-tracking --disable-doxygen-docs --disable-xmms-plugin --enable-cpplibs --enable-ogg --disable-oggtest --snip-- make[4]: Entering directory `/home/avuton/src/mpd-release-utils/src/flac.git/src/libFLAC' CC bitmath.lo /bin/bash ../../libtool --silent --tag=CC --mode=compile i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../.. -DFLaC__INLINE=inline -DNDEBUG -I../.. -I./include -I../../include -I/home/avuton/src/mpd-release-utils/build-dir/include -I/home/avuton/src/mpd-release-utils/build-dir/include -O3 -funrol...

I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) and either canonicalize NaNs or don’t support denormals. This is actually important because this kind of bitmath on floats is very commonly used as part of algorithms for complex math functions that need to get precise bit patterns from the source (similarly for the transformation of...

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure it's unsafe for some IEEE754-1985 platforms because it introduces excepti...

...# -SUFFIXES = .nasm -.nasm.o: - $(NASM) -f elf -d ELF -i i386/ $< -o $@ - lib_LTLIBRARIES = libFLAC.la if DEBUG CFLAGS += @CFLAGS@ -DFLAC__PRECOMPUTE_PARTITION_SUMS -DFLAC__OVERFLOW_DETECT @@ -15,40 +11,11 @@ if FLaC__CPU_IA32 if FLaC__HAS_NASM -libFLAC_la_SOURCES = \ - bitbuffer.c \ - bitmath.c \ - crc.c \ - cpu.c \ - encoder.c \ - encoder_framing.c \ - file_decoder.c \ - fixed.c \ - format.c \ - lpc.c \ - md5.c \ - seek_table.c \ - stream_decoder.c \ - i386/cpu_asm.nasm \ - i386/fixed_asm.nasm \ - i386/lpc_asm.nasm -else -libFLAC_la_SOURCES = \ - bitbuffer.c \ - bitmath.c \ - crc.c \ -...