similar to: Again about encoding speed of different compiles

Good evening, guys! At first, I apologize my report is a little gross, I have so little time to do checking process minutely. * RC1 RC1 can be built on VS8, 9, 10 with Debug|Release. At one point, r127264(in release_29/trunk) is needed to build with Debug on VS10. RC1 can pass clang-test with any configurations. RC1 fails llvm's check on many tests. * RC1 and patches ToT would be ready

FYI, I have confirmed it works on VS10SP1 with x64|Release. E:\llvm\build\cmake-x64-vs10>bin\Release\Fibonacci.exe 24 verifying... OK We just constructed this LLVM module: --------- ; ModuleID = 'test' (snip) --------- starting fibonacci(24) with JIT... Result: 46368 ...Takumi 2011/8/11 <gleizesd at gmail.com>: > Hello everybody, > > I have sucessfully compiled LLVM

Hi, I would like to be able to create new environments from package C code. AFAICT, this isn't allowed since both NewEnvironment and R_NewHashedEnv are declared in Defn.R. If exposing this isn't controvertial, I would submit a patch. However, I'm not sure where the declarations should go (Rdefines.h?) and whether they need to change to Rf_*. + seth

As I wrote earlier, GCC generates slow ia32 code for FLAC__lpc_compute_residual_from_qlp_coefficients_wide() and FLAC__lpc_restore_signal_wide(). So 24-bit encoding/decoding is slower for GCC compile than for MSVS or ICC compile. I took FLAC__lpc_compute_residual_from_qlp_coefficients_asm_ia32 and FLAC__lpc_restore_signal_asm_ia32 asm functions and wrote their _wide versions. -------------- next

Hello everybody, I have sucessfully compiled LLVM with CMAKE generator "Visual Studio 9 2008 Win64" (OS Windows 7). -But when I run the Fibonacci example program in "release" mode, I get a crash with this visual studio popup message : Microsoft Visual Studio C Runtime Library has detected a fatal error in Fibonacci.exe. -Here is the visual studio output:

Hi all, I've just grabbed a copy of SVN head for libogg and 'make check' is failing: ./test_framing testing single page encoding... 0, (0), granule:0 ok. testing basic page encoding... 0, (0), granule:0 1, (1), granule:6151 ok. testing basic nil packets... 0, (0), granule:0 1, (1), granule:10247 ok. testing initial-packet lacing > 4k... 0, (0), granule:0

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

I measured encoding speed of 24-bit WAV files. It turns out that 32-bit encoder made by GCC is ~1.7x times slower than 32-bit encoder made by MSVS. It seems that GCC creates inefficient code for 32bit * 32bit -> 64bit multiplication for 32-bit architecture. This problem affects FLAC__lpc_compute_residual_from_qlp_coefficients_wide() and FLAC__lpc_restore_signal_wide() functions. Is there any

They are good. I am checking with Release now. 20> Clang :: CodeGenObjC/image-info.m I will investigate it later. ...Takumi vs8 20>Failing Tests (3): 20> Clang :: CodeGenObjC/image-info.m 20> LLVM :: Transforms/SRETPromotion/basictest.ll 20> LLVM-Unit :: support/debug/SupportTests.exe/CastingTest.cast 20> Expected Passes : 8106 20> Expected Failures : 73

They are good. On VS9, it seems ARM stuff has been broken for months. ...Takumi vs8 10>-- Testing: 8725 tests, 8 threads -- 10>Testing Time: 245.20s 10> Expected Passes : 8100 10> Expected Failures : 73 10> Unsupported Tests : 552 vs9 10>Failing Tests (3): 10> LLVM :: CodeGen/ARM/bfi.ll 10> LLVM :: CodeGen/ARM/va_arg.ll 10> LLVM ::

im compiling llvm with visual studio 10. I have used cmake build app. visual studio 10 is complaining about error c2039: 'setjmp' : is not a member of llvm::Intrinsic its line 154, LowerInvoke.cpp any ideas? -- View this message in context: http://old.nabble.com/errors-when-compiling-with-visual-studio-10-tp29427176p29427176.html Sent from the LLVM - Dev mailing list archive at

also within visual studio, when i compile a window pops up saying that CMake has regenerated 29.sln files. and do i want to reload them? is this normal. what should I do? gafferuk wrote: > > im compiling llvm with visual studio 10. I have used cmake build app. > > visual studio 10 is complaining about error c2039: 'setjmp' : is not a > member of llvm::Intrinsic > its

Hi. I am interested in using the CBackend of LLVM. I have read about the problems with the current version and that David Greene has started a reimplementation. Can you tell me about its current state? Furthermore, I use Microsoft Visual Studio. The "Getting started with MVC" documents for release 2.8 say "To emphasize, there is no C/C++ front end currently available" but

Hi. This is the qmail-send program at relay.spectranet.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <jack@yahoo.com>: 64.156.215.6 does not like recipient. Remote host said: 553 VS10-RT Possible forgery or deactivated due to abuse (#5.1.1) Giving up on 64.156.215.6. ---

Hi, The Object/nm-archive test is failing for me on 64-bit Windows. It started recently, possibly with r166767. The output is as follows: 12> ******************** TEST 'LLVM :: Object/nm-archive.test' FAILED ******************** 12> Script: 12> -- 12> C:/dev/llvm/build/bin/Debug/llvm-nm.EXE c:\dev\llvm\test\Object/Inputs/archive-test.a-coff-i386 |

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

Compile with -O3 -m32 (see <https://godbolt.org/z/yCpBpM>): long lsign(long x) { return (x > 0) - (x < 0); } long long llsign(long long x) { return (x > 0) - (x < 0); } While the code generated for the "long" version of this function is quite OK, the code for the "long long" version misses an obvious optimisation: lsign: # @lsign mov

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

For the simple C program below I show the output of clang and the output of the VS compiler (I am on windows). Maybe this is obvious to you, but is it really faster to do 2 multiplications, 3 movl instructions, 2 shifts, 1 add, and 1 substract than to do 1 mov, 1 cdq, and 1 idiv? I run into this while trying to understand why my code runs slower with llvm than a comparable program on windows.