similar to: [PATCH 2] more changes in bitmath.h

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

More or less detailed explanation 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

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 ||

--- 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 /* Will never be emitted for MSVC, GCC, Intel compilers */

lvqcl wrote: > More or less detailed explanation of this patch. I've applied part of that patch. > 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is > a pointer to unsigned long (4-byte int). On windows, yes, unsigned long is 4 bytes for both 32 and 64 bit versions. This is not true for most Unices. > However _BitScanReverse64() is called with a pointer to

--- 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 inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

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;

Hello, I had some difficulties compiling the current git ( http://git.xiph.org/?p=flac.git;a=commit;h=a7e3705d051bafd1cae90f6605287cc1d9f2a18d ) using the Ubuntu 12.04 supplied MinGW32 cross compiler: I configured the FLAC build with --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux but ran into several linker problems. Are these options somehow wrong? It worked fine when

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, }; return (word) > 0xffffff ?

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

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > > > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > > other physical register which may be holding a live value used > > somewhere else. How do I make regalloc aware so that it saves the > > value before

Hi all, Some non trivial legalization of operations which aren't supported by the backend would benefit from having the optimizer pass on them. I noticed some example trying to optimize various pieces of code over the past weeks. One offender is the cttz/ctlz intrinsic when defined on 0. On X86, BSR and NSF are undefined on 0, and only recent CPU have the LZCNT and TZCNT instructions that

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Patch applied, tested, commited and pushed. Great. But, what about my other patches? I admit that many of them aren't necessary, but (imho) a couple of them are important. I can explain in detail why I think this.

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Well first of all, none of them apply :-). I'll try to redo the necessary patches with git. > * Remove restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and

Ben Allison wrote: > There's a more few issues for compiling on MSVC. I put together a patch. > > Here's a quick rundown: > * must use __inline keyword with static inline functions (bitmath.h) If you include "share/compath.h" you will get a inline #defined as __inline when _MSC_VER is defined. I'd prefer a single diffinition of that in one place and one place

Hello, just trying to use the dragonegg plugin with gcc on my project. Unfortunately I get an /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include/ia32intrin.h:170:35: error: unsupported target builtin ‘__builtin_ia32_bsrdi’ used error. I use (and need) the "bsr" (bit scan reverse) instruction. So it seems it isn't implemented (yet). Can I safely use gcc inline assembly

I may be wrong here, but legalizing early seems like something that is more likely to prevent optimizations than it is to encourage them. But I guess I don't follow why things like TTI, TII and TLI queries don't suffice for this. CodeGenPrepare will break this sequence up. I would imagine that if the target returns false for isCheapToSpeculateCtlz() and false for canInsertSelect(), the

El 03/05/12 12:19, Miroslav Lichvar escribi?: > Hi Josh, > > nice to see you here again. > > On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: >> (Jumping in again, maybe at the wrong point since this doesn't seem >> to involve encoding, but here goes.) >> >> Miroslav's patches have always been high-quality for sure. But >>

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:

There are preprocessor definitions in bitreader.c and bitwriter.c: /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this you must also change the following #defines down to SWAP_BE_WORD_TO_HOST below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ #define