search for: _bitscanreverse64

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 variable inside...

...tatic.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 same type as FLAC__uint32 (= unsigned int) but it doesn't really matter sinc...

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.

..."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't synonymous we *want* that to be a compile error! > Other than that, it compiles everything without errors. Thanks! Erik -- ---...

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

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 I would not call that a...

From the neighbouring list, http://lists.xiph.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

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

...ned 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` should be safe. Furthermore if they aren't synonymous we > > *want* that to be a compile error! > > It's synonymous to uint32_t, b...

...C__ == 3 && __GNUC_MINOR__ >= 4)) + return sizeof(FLAC__uint64) * CHAR_BIT - 1 - __builtin_clzll(v); +/* Sorry, only supported in win64/Itanium.. */ +#elif (defined(_MSC_VER) && (_MSC_VER >= 1400)) && (defined(_M_IA64) || defined(_WIN64)) + FLAC__uint64 idx; + _BitScanReverse64(&idx, v); + return idx ^ 63U; #else - -unsigned FLAC__bitmath_ilog2(FLAC__uint32 v); -unsigned FLAC__bitmath_ilog2_wide(FLAC__uint64 v); - +/* Brain-damaged compilers will use the fastest possible way that is, + de Bruijn sequences (http://supertech.csail.mit.edu/papers/debruijn.pdf) +...

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