similar to: [PATCH] Fix build with MSVC++

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: > On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) >> and Anton kindly explained that LLVM is doing the right thing as per the >> ABI (the GCC ABI, I'll add). >> >>  1. Is there a LLVM way of

Recently I downloaded MSVC++2005 Express Edition and it turns out that it wasn't possible to compile all files without several changes: 1) FLAC.sln has one extra "EndProject" line --- a\FLAC.sln 2013-06-17 11:57:09.000000000 +0400 +++ b\FLAC.sln 2013-08-16 20:19:34.630486700 +0400 @@ -157,7 +157,6 @@ EndProject Project("{4cefbc7c-c215-11db-8314-0800200c9a66}") =

On Thu, Aug 1, 2013 at 1:06 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > * To understand why they chose to work on MS C++ ABI compatibility > instead of other most basic missing features that preclude using > Clang for serious C++ development. I'll be grateful if anyone > involved on the MS C++ ABI comments on this (it was already mentioned > that Wine is

On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) > and Anton kindly explained that LLVM is doing the right thing as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what

Óscar Fuentes <ofv at wanadoo.es> writes: > BTW, it's even worse, as aggregates passed by value are, well... passed > by value, contrary to the 386 unix ABI which uses pointers. I'm afraid > that this has no so easy solution as the sret issue. Is there any LLVM > target where aggregates are "really" passed by value? This is not entirely true. MSVC never uses

Hi, is there any news about this problem? How hart it will be to resolve this compatibility problem with Visual Studio functions ? This is really great problem for my project with should call may different function compiled by Visual Studio!!! Here is also problem that is looking similar. http://llvm.org/bugs/show_bug.cgi?id=5046 -- View this message in context:

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Is there not a later free (as in free beer) version? There are also 2008, 2010 and 2012 versions. VS2012 Express requires Win7 to run (though it can create programs compatible with WinXP). VS2010 Express works on WinXP. It is possible to compile x86-64 programs with it, but it requires Platform SDK (also free). VS2005 and 2008

Chris Lattner <clattner at apple.com> writes: > This thread is odd to me. It seems that the gist of your guys' > argument is that you don't know if we will ever get full support, > therefore we don't welcome progress towards that (very useful) > goal/feature. > > If the specific proposal doesn't make make sense from a design > standpoint, that's one

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx

Hi, This page http://clang.llvm.org/docs/MSVCCompatibility.html says clang-cl supports C ++ exceptions, but I cannot compile code with simple try{}catch{} error : cannot compile this throw expression yet What am i doing wrong? -- WBR, Arkady Shapkin aka Dragon -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff

This commit https://github.com/xiph/opus/commit/94b68f341cadd5433a10d346c1c248a641d8be57 Enabled HAVE_LRINTF defined in CMake builds. As later versions of visual studio have LRINTF it got enabled by default due to precedence over SSE in MSVC. The use of lrintf is a lot slower which can easily be seen in the tests >From test result Windows X64 (similar results on X86): LRINTF 4/4 Test #4:

Did the patch 5 split / AVX fix work get merged at all, I didn't see any more mails about it? Thanks! On Tue, 14 Jan 2020 at 21:34, Marcus Asteborg <xnorpx at outlook.com> wrote: > Awesome thanks! Good comments. > > Please apply patch 1-4 and I prepare another iteration on patch 5 for you > too look at. > > //Marcus > ------------------------------ > *From:*

Is there any consensus on what's the correct fix here? Jean-Marc On 06/11/14 04:26 PM, Cameron Gutman wrote: > Yeah that's the one. > > On Nov 6, 2014 1:23 PM, "Tristan Matthews" <le.businessman at gmail.com > <mailto:le.businessman at gmail.com>> wrote: > > On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman > <aicommander at gmail.com

I would like to say opus is a great library. I have been playing with it with mingw and have found it great. I thought I would also get it working in MSVC aswell since I'm using CMake Then when I compiled I realised opus.lib was not enough. I needed celt.lib;silk_common.lib;silk_float.lib linked as well. I was wondering why mingw compiles to one lib and MSVC does not. Is there something

On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman <aicommander at gmail.com> wrote: > _WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this > on in the first place. They aren't at all meant to be x86/x86-64 specific. > At best, they're 32-bit/64-bit specific, but that's not the intended use in > the code. The correct definitions are _M_IX86 and

Yeah that's the one. On Nov 6, 2014 1:23 PM, "Tristan Matthews" <le.businessman at gmail.com> wrote: > On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman <aicommander at gmail.com> > wrote: > > _WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating > this > > on in the first place. They aren't at all meant to be x86/x86-64 >

3, no good catch attached is an updated patch //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Thursday, June 11, 2020 10:49 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches On 2020-06-08 01:39, Marcus Asteborg wrote: > 1. Build test for cmake and run the test in

Chandler Carruth <chandlerc at google.com> writes: >> And here there is no "Windows ABI" here at all. Because every compiler >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said >> that the proposal naming is confusing. >> > > I don't know anything about Borland, and I don't think that matters. But I > think that the

_WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this on in the first place. They aren't at all meant to be x86/x86-64 specific. At best, they're 32-bit/64-bit specific, but that's not the intended use in the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. I sent a patch to this ML that fixed these a few months ago but it was