search for: flac__uint32

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In func...

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> 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 it is > I couldn't image FLAC working correctly > if it wasn't. > > Erik

1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 1400) is always true and can be removed. 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so FLAC__clz_soft_uint32() should have the same argument type. 3) The patch removes unnecessary parentheses around 'word' variable. 4) It also replaces "sizeof(FLAC__uint32) * CHAR_BIT - 1 - FLAC__clz_uint32(v)" with "FLAC__clz_uint32(v) ^ 31U" (and the same f...

...r.c: In function 'FLAC__bitwriter_write_utf8_uint64': bitwriter.c:324:19: warning: inlining failed in call to 'FLAC__bitwriter_write_raw_uint32.constprop': --param large-function-growth limit reached [-Winline] inline FLAC__bool FLAC__bitwriter_write_raw_uint32(FLAC__BitWriter *bw, FLAC__uint32 val, unsigned bits) ^ bitwriter.c:826:9: warning: called from here [-Winline] ok &= FLAC__bitwriter_write_raw_uint32(bw, 0x80 | (FLAC__uint32)((val>>6)&0x3F), 8); ^ bitwriter.c:324:19: warning: inlining failed in call to 'FLAC__bitwriter_write_raw_ui...

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 it is Well I've just pushed a patch that purges the code base of `unsigned`. Please test and let us know how...

.../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); v|=v>>1; v|=v>>2; v|=v>>4; v|=v>>8; v|=v>>16; v=(v>>1)+1; return m+DEBRUIJN_IDX32[v*0x77CB531U>>27&0x1F];

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 it is > > Well I've just pushed a patch that purges the code base of `unsigned`. &gt...

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

...ath.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 since both of them are 4-byte unsigned integers. However, _BitScanReverse64 expects a pointer to a 4-byt...

..._bitreader_read_rice_signed_block(): called from read_residual_partitioned_rice_() with a pointer to FLAC__int32, not to int (as its 2nd parameter). * function FLAC__bitreader_read_unary_unsigned(): sometimes it is called with a pointer to unsigned as its 2nd parameter, sometimes with a pointer to FLAC__uint32. Is it Ok to pass FLAC__int32* in a function that expects int* ? (the same question for FLAC__uint32* and unsigned*)

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

...) = 3 - * ilog2(10) = 3 - * ilog2(11) = 3 - * ilog2(12) = 3 - * ilog2(13) = 3 - * ilog2(14) = 3 - * ilog2(15) = 3 - * ilog2(16) = 4 - * ilog2(17) = 4 - * ilog2(18) = 4 - */ - -#ifndef __GNUC__ - -/* For GNUC, use static inline version in include/private/bitmath.h. */ - -unsigned FLAC__bitmath_ilog2(FLAC__uint32 v) -{ - unsigned l = 0; - if (v == 0) - return 0; - while(v >>= 1) - l++; - return l; -} - -unsigned FLAC__bitmath_ilog2_wide(FLAC__uint64 v) -{ - unsigned l = 0; - if (v == 0) - return 0; - while(v >>= 1) - l++; - return l; -} -#endif - /* An example of what FLAC__bitmath_s...

...from FLAC files in 64-bit and it works without any issues. This now leave me a bit confused, since it should have issues(!). Using the MS 64-bit compiler on Windows 7/2008R2 64-bit. Static libFLAC compiled with compiler default 8 byte boundary alignment. Now consider this: typedef struct { FLAC__uint32 length; FLAC__byte *entry; } FLAC__StreamMetadata_VorbisComment_Entry; The compiler (with default settings) should interpret this as typedef struct { FLAC__uint32 length; uint32_t __padding; FLAC__byte *entry; } FLAC__StreamMetadata_VorbisComment_Entry; Sizeof structure: 32-bit...

> While you are at it, can you check/fix the following warning > ? > > metadata.cpp:812:98: warning: narrowing conversion of > 'strlen(((const > char*)string))' from 'size_t {aka long unsigned int}' to > 'FLAC__uint32 > {aka unsigned int}' inside { } is ill-formed in C++11 > [-Wnarrowing] > > > Thanks ! Yeah sure! I don't get that error because I'm on a 32 bit OS by the way. The message makes it pretty clear you are compiling on 64 bit, so the size_t returned by strlen is 64 bits,...

...nline 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 only. > * change instances of uint32_t in bitwriter.c to FLAC__uint32 Can we include <inttypes.h> to fix this instead? > * functions marked inline cannot be used within another C file (e.g. > FLAC__bitreader_get_input_bits_unconsumed produces the linker error "error > LNK2001: unresolved external symbol > _FLAC__bitreader_get_input_bits_uncon...

...rds-br->consumed_words)*FLAC__BITS_PER_WORD + br->bytes*8 - br->consumed_bits; } @@ -499,7 +495,7 @@ FLAC__bool FLAC__bitreader_read_raw_uint64(FLAC__BitReader *br, FLAC__uint64 *va return true; } -FLaC__INLINE FLAC__bool FLAC__bitreader_read_uint32_little_endian(FLAC__BitReader *br, FLAC__uint32 *val) +inline FLAC__bool FLAC__bitreader_read_uint32_little_endian(FLAC__BitReader *br, FLAC__uint32 *val) { FLAC__uint32 x8, x32 = 0; diff --git a/src/libFLAC/bitwriter.c b/src/libFLAC/bitwriter.c index 44914d1..1f005a3 100644 --- a/src/libFLAC/bitwriter.c +++ b/src/libFLAC/bitwriter.c @@ -75...

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.

...16_t etc, at least for internal code. > I am slowly doing that when I touch code. > > I don't think this should be done at the API level without an API > version bump and I don't think that is currently worth it. IMHO in this case it makes sense to change: unsigned *val -> FLAC__uint32 *val int *val -> FLAC__int32 *val int vals[] -> FLAC__int32 vals[] or FLAC__int32* vals: that is: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, FLAC__uint32 *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, FLAC__int32 *val,...

...h: I hoped that somebody else will find what's wrong and will create a bugreport... Well, here is the link: https://connect.microsoft.com/VisualStudio/feedback/details/2659191/incorrect-code-generation-for-x86-64 It seems that MSVC miscompiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); into movq QWORD PTR [rsi], xmm2 So it incorrectly copies 8 bytes from mm_sum to abs_residual_partition_sums[partition] (it should copy 4 lower bytes and zero out 4 upper bytes). It should be something like movd eax, xmm2 movq QWORD PTR [rsi], rax

...g list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev -------------- next part -------------- diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c index b9df19a..808d55d 100644 --- a/src/libFLAC/cpu.c +++ b/src/libFLAC/cpu.c @@ -269,9 +269,9 @@ void FLAC__cpu_info_x86(FLAC__uint32 level, FLAC__uint32 *eax, FLAC__uint32 *ebx __cpuid(cpuinfo, ext); if((unsigned)cpuinfo[0] >= level) { #if FLAC__AVX_SUPPORTED - __cpuidex(cpuinfo, ext, 0); /* for AVX2 detection */ + __cpuidex(cpuinfo, level, 0); /* for AVX2 detection */ #else - __cpuid(cpuinfo, ext); /* some old compi...