search for: _bitscanreverse

lvqcl wrote: > Also MSVC fails because src/libFLAC/include/private/bitmath.h now > contains "uint32_t long idx" instead of "unsigned long idx". Ah, missed that because it was MSVC code. They should be `uint64_t`. > According to MSDN _BitScanReverse*() functions have signatures: > unsigned char _BitScanReverse(unsigned long *, unsigned long); > unsigned char _BitScanReverse64(unsigned long *, unsigned __int64); The `unsigned long` type should be synonymous with `uint64_t` so using `uint64_t` should be safe. Furthermore if they aren'...

lvqcl wrote: > > Ah, missed that because it was MSVC code. They should be `uint64_t`. > > No, sizeof(unsigned long) is always 4 on Windows. > See http://www.viva64.com/en/t/0012/ Bah! Trust Windows to be different :). > >> According to MSDN _BitScanReverse*() functions have signatures: > >> unsigned char _BitScanReverse(unsigned long *, unsigned long); > >> unsigned char _BitScanReverse64(unsigned long *, unsigned __int64); > > > > The `unsigned long` type should be synonymous with `uint64_t` so using > > `uint64_t...

...le to add /D "_USE_MATH_DEFINES" as an additional option to libFLAC_static.vcproj and libFLAC_dynamic.vcproj. Don't know what is better. What do you think? > * bitmath.h: 1 typo, 1 warning : I don't see why the type has to change. Declarations from MSDN: unsigned char _BitScanReverse(unsigned long * Index, unsigned long Mask); unsigned char _BitScanReverse64(unsigned long * Index, unsigned __int64 Mask); FLAC uses them as: _BitScanReverse(FLAC__uint32* idx, FLAC__uint32 v); and _BitScanReverse64(FLAC__uint64* idx, FLAC__uint64 v); AFAIK unsigned long is not the...

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> > Ozkan Sezer wrote: >> > >> >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> >> warnings with platforms (e.g. djgpp) where int32_t is long: >> > >> > Is `sizeof int == 4` though? >> >> Yes, obviously

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

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.

...FLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -34,28 +34,126 @@ #include "FLAC/ordinals.h" +/* for CHAR_BIT */ +#include <limits.h> -#if defined(__GNUC__) +#if defined(_MSC_VER) && (_MSC_VER >= 1400) +#include <intrin.h> /* for _BitScanReverse* */ +#endif + +/* Will never be emitted for MSVC, GCC, Intel compilers */ +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, + 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,...

...z, lzcnt depending on - * -march= setting or to a software rutine in exotic machines. */ + * -march= setting or to a software routine in exotic machines. */ return __builtin_clz(v); #elif defined(_MSC_VER) && (_MSC_VER >= 1400) - FLAC__uint32 idx; + unsigned long idx; _BitScanReverse(&idx, v); - return idx ^ 31U; + return (unsigned)idx ^ 31U; #else return FLAC__clz_soft_uint32(v); #endif

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 FLAC__uint64 > (8-byte int). IMHO it's a bug...

Hi, Bjoern's solution of adding the line: #pragma intrinsic(_BitScanReverse) after the: # include<intrin.h> worked for me, so it solves my debug build problem. However, you still might want to change the location of ec_ilog's prototype in entcode.h for those platforms that don't have an intrinsic like that. Cheers, John Ridges

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;

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Hi, so here it is, LZ4 compression method inside btrfs. The patchset is based on top of current Chris'' for-linus + Andi''s snappy implementation + the fixes from Li Zefan. Passes xfstests and stresstests. I haven''t measured performance on wide range of hardware or workloads, rather wanted to publish the patches before I get distracted again. I''d like to ask