similar to: 'out of range' Warnings Building FLAC

> I've been building and testing FLAC and have run a problem. I get a > number of 'integer constant out of range' warnings during the make, > and these give rise to failures in the test suite: [...] > The problem is that gcc 2.7.2.3 wants a 'ULL' suffix for integer > constants of type 'unsigned long long' (as typedef'ed by FLAC__uint64). >

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

Hello everyone! Can we add low-level seek functions into libFLAC? I'm using libFLAC in a program where file operations can't be completed synchronously from those user callback procedures that libFLAC calls when it needs to perform read, seek, etc. So I had to modify libFLAC in a way that it doesn't call any user callbacks while performing seeking. Although I added a dirty hack for

Hi, I've some troubles setting up the dict based quota plugin for mdbox, it always returns a error when lmtp tries to deliver an e-mail: Apr 8 12:40:16 mb07 dovecot: lmtp(3001, asmarre at ull.es): Error: fstat(/sharedfs/10.4.1.107/ull.es/54/asmarre/dovecot-quota.lock) failed: No such file or directory Apr 8 12:40:16 mb07 dovecot: lmtp(3001, asmarre at ull.es): Error: file dict commit:

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Hi @ll, targetting i386, LLVM/clang generates wrong code for the following functions: unsigned long __bswapsi2 (unsigned long ul) { return (((ul) & 0xff000000ul) >> 3 * 8) | (((ul) & 0x00ff0000ul) >> 8) | (((ul) & 0x0000ff00ul) << 8) | (((ul) & 0x000000fful) << 3 * 8); } unsigned long long __bswapdi2(unsigned long

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

share/compat.h contains the following code: /* adjust for compilers that can't understand using LLU suffix for uint64_t literals */ #ifdef _MSC_VER #define FLAC__U64L(x) x #else #define FLAC__U64L(x) x##LLU #endif I tested MSVS 2005 and indeed it doesn't support LLU suffix, but it can compile a code with ULL suffix. Also, http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html mentions ?ULL?

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

Hi all! I have a problem to get _all_ images from flac file. I have flac file with 3 images inside ( FLAC__METADATA_TYPE_PICTURE ) How to get _all_ images with bool FLAC::Metadata::get_picture() func? This function is wrapper FLAC__bool FLAC__metadata_get_picture(). flac-1.2.1/src/libFLAC/metadata_iterators.c: ... 285 FLAC_API FLAC__bool FLAC__metadata_get_picture(const char *filename,

I just compiled the two attached files in 32-bit mode and ran it. It printed efcdab8967452301. I verified via objdump that the my_bswap function contains the follow assembly which I believe matches the assembly you linked to on godbolt. _my_bswap: 1f70: 55 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8

bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

On 12 June 2010 00:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: >> Hi Eli, >> >> On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote:

Hi all, The code currently in CVS gives a compile warning: memory.c: In function 'FLAC__memory_alloc_aligned': memory.c:52: warning: cast from pointer to integer of different size memory.c:52: warning: cast to pointer from integer of different size The patch below fixes this warning by detecting the sizeof (void*) at configure time and then using that for a little pointer

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The

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

Hello, I've a problem with seeking using libFLAC++ API. The call to seek_absolute always returns with false, whatever I do. I tried many different ways, finally I tried to reduce my added code to near zero, so I used the cpp decode example in ...\flac-1.2.1\examples\cpp\decode\file\.main.cpp and added only one line: bool b=decoder.seek_absolute(1000); right before ok =

Yeah I had a think about it, and I think intrinsics are the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the

I was able to get the loop to increment from -999 to 0 using IR directly. That got rid of the cmpq. The carry i was after was able to be obtained using the intrinsic @llvm.uadd.with.overflow.i64, however there is no way to add with carry and have it realise that the resulting *carry out* cannot exceed 1. It actually writes the carry to a byte, and then uses logical operations on it, which slows