similar to: [LLVMdev] Self-compiling clang on Windows

Displaying 20 results from an estimated 1100 matches similar to: "[LLVMdev] Self-compiling clang on Windows"

2016 Sep 01
1
[PATCH] vs2015: include files added in 76674fea
--- win32/VS2015/opus.vcxproj | 2 ++ win32/VS2015/opus.vcxproj.filters | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/win32/VS2015/opus.vcxproj b/win32/VS2015/opus.vcxproj index d9aaa03..f55ea37 100644 --- a/win32/VS2015/opus.vcxproj +++ b/win32/VS2015/opus.vcxproj @@ -852,6 +852,7 @@ <ClInclude Include="..\..\celt\vq.h" /> <ClInclude
2016 Jul 15
3
[PATCH 1/4] Create a simple project to create version.h to run before any other
Avoids trying to create and replace version.h more than once which led to file-locking errors with multicore builds. --- Makefile.am | 1 + win32/VS2015/celt.vcxproj | 48 +++++++++++++++++--------- win32/VS2015/generate_version.vcxproj | 65 +++++++++++++++++++++++++++++++++++ win32/VS2015/opus.sln | 32 ++++++++++++++++-
2015 Mar 13
1
[RFC PATCH v3] Intrinsics/RTCD related fixes. Mostly x86.
From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not
2015 Mar 12
1
[RFC PATCHv2] Intrinsics/RTCD related fixes. Mostly x86.
From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not
2016 Sep 09
2
[PATCH 1/3] appveyor: include opus.dll and opus.exp files if available
Using -i should prevent failing if the files don't exist. --- appveyor.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appveyor.yml b/appveyor.yml index c85b0b1..ad9c6c0 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -17,7 +17,7 @@ build: verbosity: minimal after_build: -- cmd: 7z a opus.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\opus.lib include\*.h +- cmd: 7z
2015 Mar 02
13
Patch cleaning up Opus x86 intrinsics configury
The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in
2016 Jan 05
2
llvm.natvis should be included when generating LLVM.sln
As of Visual Studio 2015, natvis files can be included as part of individual projects <http://blogs.msdn.com/b/vcblog/archive/2015/09/28/debug-visualizers-in-visual-c-2015.aspx>, a much better method than manually copying the file to an specific directory in %USERPROFILE%. I think it should be included in one of the CMakeLists.txt files, does anybody know how I can add it? Sincerely,
2015 Mar 18
5
[RFC PATCH v1 0/4] Enable aarch64 intrinsics/Ne10
Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:
2015 Mar 31
6
[RFC PATCH v1 0/5] aarch64: celt_pitch_xcorr: Fixed point series
Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]
2015 May 08
8
[RFC PATCH v2]: Ne10 fft fixed and previous 0/8]
Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:
2015 May 15
11
[RFC V3 0/8] Ne10 fft fixed and previous
Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest
2015 Apr 28
10
[RFC PATCH v1 0/8] Ne10 fft fixed and previous
Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work
2004 Dec 14
1
[LLVMdev] __time_t type instead of __time64_t inwin32/TimeValue.cpp
Replace __time_t with time_t in my question. I've compiled function: std::string TimeValue::toString() const { // Alas, asctime is not re-entrant on Windows... //hb: __time64_t ourTime = this->toEpochTime(); time_t ourTime = this->toEpochTime(); //hb: char* buffer = ::asctime(::_localtime64(&ourTime)); char* buffer = ::asctime(::localtime(&ourTime)); std::string
2015 Jun 09
2
[LLVMdev] msbuild and clang
Okay, so trying a straight compile of the Python interpreter with clang-cl, I used the following commands: cd \python-2.7.10\pcbuild copy C:\llvm\build\Release\bin\clang-cl.exe cl.exe rd /q /s amd64 rd /q /s win32-temp-debug rd /q /s win32-temp-release rd /q /s x64-temp-debug rd /q /s x64-temp-release msbuild /p:Configuration=Release /v:diag /fileLogger pcbuild.sln (The second line is the one
2015 Jun 11
2
[LLVMdev] Self compiling latest clang from SVN
I tried checking out the latest llvm/clang from SVN (as of a few hours ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a version check, so I repeated the technique of compiling with Microsoft C++ first, then using the resulting clang-cl.exe). It fails with a bunch of error messages along the lines of: LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external
2018 Sep 17
2
build llvm fails under win7 x64/VS2017
my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON
2011 Jun 24
2
[LLVMdev] Missing symbols in pass stack trace
> Try building with "make VERBOSE=1", which will show you the > command-lines passed to the compiler/linker. Post the output here. there you go: > cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make VERBOSE=1 > llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) > if g++ -I/home/cafxx/Projects/llvm2/include >
2018 May 16
0
Windows build strangeness
Here are a couple of representative errors. C:\Dev\upstream\gitmono is where I keep my clone. "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target) (1) -> "C:\Dev\upstream\gitmono\wbuild\unittests\Support\DynamicLibrary\SecondLib.vcxproj" (default target) (170:2) -> c1xx : fatal error C1083: Cannot open source file:
2015 Jun 12
2
[LLVMdev] Self compiling latest clang from SVN
Makes sense, yeah, trying something in a different environment is usually a good way to find problems. I had indeed moved the renamed clang-cl.exe to a different directory, but when I move it back into its home directory and retry the build, I get the same errors. On Thu, Jun 11, 2015 at 11:16 PM, Reid Kleckner <rnk at google.com> wrote: > Thanks for trying the self-host, it's
2018 May 16
2
Windows build strangeness
I think MSBuild isn't capable of re-running cmake and then reloading the project files when CMakeLists.txt changes. It re-runs cmake, but then continues the build with the stale projects. That probably explains the "PipSqueek.cxx doesn't exist" errors. As for the link error, it could also be caused by things like a file rename not getting picked up by MSBuild. The fix is