similar to: [PATCH] remove MSVC6 workaround

Anybody knows the reason for the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 /

Erik de Castro Lopo wrote: > That's a really good question. Haven't was already dropped support for > MSVC6? If so, we should drop this #ifdef hackery. Can test this without > the hackery for versions of MSVC > 6? I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports is MSVS 2005 anyway. It can compile FLAC__uint64 -> FLAC__double conversion

Here's a new version of a patch that fixes a problem with MSVC2105 update2, but it doesn't disable any optimization, so the resulting encoding performance should be almost unaffected by this workaround. MSVC compiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); into this: movq QWORD PTR [rsi], xmm2 while it should be movd

1) Some time ago all project files for MSVC 6 were removed; it makes sense to remove the code that is necessary only for MSVC 6 and older compilers. --- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400 @@ -285,14 +285,7 @@ # ifdef USE_TRY_CATCH_FLAVOR _try { __asm { -# if _MSC_VER <= 1200 - /* VC6 assembler

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in

It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)

Erik de Castro Lopo wrote: > Unfortunately I've lost/forgotten my Xiph SVN password. While I get > that sorted out for the real release, the pre-releases are here: > > http://mega-nerd.com/tmp/flac-1.3.2pre1-win.zip > http://mega-nerd.com/tmp/flac-1.3.2pre1.tar.xz Forgot to mention that I have tested this on x86_64/linux, armhf/linux and powerpc/linux. Erik --

07.06.2024 20:52, Jeremy Allison wrote: > Fair enough. Can you post a minimal smb.conf and directory > setup that reproduces the problem and how to demo it with smbclient > command lines please ? I know I'm asking to be spoon-fed but my time for > Samba these days is quite limited and this would aid immensely > in creating a properly tested fix. You're not asking to be

As I wrote earlier, MSVC 2015 U2 incorrectly compiles stream_encoder_intrin_*.c files for x86-64 platform. As a result, flac works, but compression ratio is close to 1. This patch disables some compiler optimizations, and compression ratio reverts back to normal values. -------------- next part -------------- A non-text attachment was scrubbed... Name: msvc_bug.patch Type: application/octet-stream

Erik de Castro Lopo wrote: >> As I wrote earlier, MSVC 2015 U2 incorrectly compiles >> stream_encoder_intrin_*.c files for x86-64 platform. >> As a result, flac works, but compression ratio is close to 1. >> This patch disables some compiler optimizations, and >> compression ratio reverts back to normal values. > > Rather than having the same chunk of code in

Patch is here: https://github.com/openwrt/packages/commit/1263599f96f13f11d719ce336dfb6a639b32de98 . Probably needs to be modified for inclusion into mainline.

In stream_encoder.c there's the following code: #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */ #else if(mean <= 0x80000000/8) { /* 32-bit arch: use 32-bit math if possible */ #endif A) How to properly check for 64-bit architectures? I can check for "defined

The patch does the following: 1. splits lpc_x86intrin.c to lpc_intrin_sse.c and lpc_intrin_sse2.c 2. adds FLAC__lpc_compute_residual_from_qlp_coefficients_intrin_sse2() function to lpc_intrin_sse2.c 3. adds lpc_intrin_sse41.c with two ..._wide_intrin_sse41() functions (useful for 24-bit en-/decoding) 4. adds precompute_partition_info_sums_intrin_sse2() / ...ssse3() and disables

This set of patches removes PPC/Altivec code from FLAC. I decided to split the patch into 5 parts to make it more simple: 1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16* from lpc.h and stream_decoder.c 2) removes PPC-specific code from cpu.c and cpu.h 3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk 4) removes as/gas/PPC-specific stuff from configure.ac and

There was a fix for a bug in MSVC 2015 update2: https://github.com/xiph/flac/commit/94a61241b02064c7d9fe508f72a742f2a90b8492 It seems that it's not the only version affected, see comment from 40th in this commit. Also, JRMC is affected: https://yabb.jriver.com/interact/index.php/topic,115742.0.html So, it makes sense to remove version check: better safe than sorry, and performance impact

Ozkan Sezer wrote: > On 8/21/13, lvqcl <lvqcl.mail at gmail.com> wrote: > > 1) Some time ago all project files for MSVC 6 were removed; it makes sense > > to remove the code that is necessary only for MSVC 6 and older compilers. > > > > One may still compile using command line instead of a project file. Does > it really hurt keeping such code? Its crufty old

About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense

Martijn van Beurden wrote: > Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. > > > CC lpc_intrin_sse2.lo > > CC lpc_intrin_sse41.lo > > CC md5.lo > > md5.c: In function

lvqcl wrote: > > These versions of Visual Studio don't have stdint.h and > > all [u]intNN_t types. But now these types are everywhere > > in FLAC codebase. > > Here is the patch that fixes the problem: > it moves definitions of all [u]intNN_t types from share/compat.h > into new file share/msvc2005_int.h and then includes this file > into all files (via

On Fri, Jun 07, 2024 at 09:59:14PM +0300, Michael Tokarev via samba wrote: >07.06.2024 20:52, Jeremy Allison wrote: > >>Fair enough. Can you post a minimal smb.conf and directory >>setup that reproduces the problem and how to demo it with smbclient >>command lines please ? I know I'm asking to be spoon-fed but my time for >>Samba these days is quite limited and