similar to: LLVM 3.9.1 build race?

Hi Justin, > This looks like something I fixed recently, in r290271: ... ... > The tablegen build adopted USES_TERMINAL for this same reason in > r280748. I applied the 2 patches you mentioned above on my 3.9.1 tree and although the build seems to go along nicely than the earlier reported symptoms I can still see LLVMSupport being built a bit too many times than expected. $ cat

Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

Try as I might I can't seem to get LLVM to bulid using clang/clang++. No matter what I do it insists on using /usr/bin/cc and /usr/bin/c++ which are gcc. Am I missing something obvious? I vaguely remember some document describing a stage1 compiler built by your old toolchain and a stage2 compiler but I can't find the steps to do that any more. $ CC=/usr/local/bin/clang

Hi, Recently my libcxx enabled llvm/clang builds has started to fail in stage2. I must admit I am stomped because I cannot make sense of the error: [ 723s] FAILED: /home/abuild/rpmbuild/BUILD/llvm/stage1/bin/clang++ -DLLVMSupport_EXPORTS -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W

Ok looks like r207606 regressed this. CC'ing Niko. Niko, please see the messages below. This is on openSUSE 13.1 both on i586 and x86-64. Reverting r207606 fixes the second stage bootstrap. On Sun, May 11, 2014 at 10:19 PM, İsmail Dönmez <ismail at donmez.ws> wrote: > I did a diff -u broken.ii working.ii and the difference explains the > problem: > > @@ -36617,7 +36628,7

I'm trying to compile LLVM with musl libc library. The compilation process fails on the following: x86_64-linux-musl-g++ -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter

I noticed a problem with llvm-config.exe on Windows: >"c:\Users\andy\llvm+clang-6.0.0rc2-win64-msvc-release\bin\llvm-config.exe" --system-libs psapi.lib shell32.lib ole32.lib uuid.lib But then when I link against LLVM and these libs, I get: lld: error: LLVMSupport.lib(Process.obj): undefined symbol: __imp_CryptAcquireContextW lld: error: LLVMSupport.lib(RandomNumberGenerator.obj):

I am updating our out-of-tree copy of LLVM to track the head (revision #272991 specifically). I have it building successfully with VC++ 2013 and CMake v3.5.2 on Windows, and with GCC v4.8.5 and CMake v3.5.2 on CentOS; but when I try building on Windows using Cygwin32 I get the following build failures: [ 4%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o In file

*System:* Debian Linux Sid/Unstable amd64 *LLVM/Clang:* Trunk *Scenario:* In the past couple of days I've been compiling against trunk I get two separate and spurious hang ups with CMake. *Note:* I build against more than just X86 follow along the progress of other platforms, though just building for X86 produces the same results below. *Assumption:* Configure cmake with prior built

Hello LLVM developers, Following some hints on this mailing list earlier this year on how to make clang faster than stock llvm.org builds I have implemented a script that builds a PGO optimized version of clang by following the guide here: http://llvm.org/docs/HowToBuildWithPGO.html This works great on macOS and Linux - we gained almost 15% in our project with this technique. I am now looking at

Thanks Dimitry. That worked. I see some warnings in my compilations: > Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/IntEqClasses.cpp.o > [ 2%] clang-3: warning: argument unused during compilation: '-nostdinc++' > Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/IntrusiveRefCntPtr.cpp.o > clang-3: warning: argument unused during compilation:

I'm trying to get clang 3.6.1 to compile itself on Windows, using this command line: msbuild /p:Configuration=Release /p:CLToolExe=clang-cl.exe /p:CLToolPath=c:\llvm\build\Release\bin\ /p:TrackFileAccess=false /p:Platform="x64" /fileLogger ALL_BUILD.vcxproj It barfed on an occurrence of __try but that was only in a test file so I commented it out and retried. Now it's getting

Googling indicates that cygwin doesn't have that functionality. Or, at least, didn't in 2010, when someone asked about the same problem: https://cygwin.com/ml/cygwin/2010-01/msg00596.html "cygwin has only dlsym() not the SGI DL_info + dladdr() yet. clang just needs it to get the path for the CIndex dll. This should be possible with the code in the LLVM_ON_WIN32 section, and convert

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T,

Hi folks, In our scientific simulation tool, we set up our build system to link against LLVMSupport to print stack traces for debugging purposes, also from other compilers. This works very well on most hosts, but we fail to make it work with gcc on a Cray XC 40 cluster. They have a very restrictive toolchain setup (everything is controlled by the “module” command; you never get to see any real

Not sure what would have changed to break this but os_defines.h citing features.h is no longer being found in the system paths. > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h:40:10: > fatal error: > * 'features.h' file not found > #include <features.h>* > ^ > > #include <stdlib.h> >

If cmake happens to detect GCC for the C compiler and Clang for the C++ compiler, then a manual override of either the C compiler or SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening on my Darwin build environments: -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is Clang 4.1.0 Without the manual overrides, all C sources fail to compile

Dear testers, 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. This took a little longer than I'd hoped, but I think the branch is in a decent state now. There are still open merge requests and bugs, but I'd like to get the real testing started to see where we're at. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs,

Hi All, I am trying to build the 'lld' linker on Mac OS 10.9, but during the build, I am getting the errors. Following are the steps that I have followed: 1.     I have downloaded the ‘llvm-stable’ source code from the following location:   https://github.com/llvm-mirror/llvm/tree/stable   2.     Machine details(on which llvm source code isbeing built) are as follows: $ sw_vers

Looks good to me! I can commit this for you today. Thanks! -Chris > On Oct 19, 2015, at 2:40 PM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks like the LLVMSupport patch didn't get everything -- build failed in the > same way on libLLVMTableGen. Problem/solution looked the same as for > LLVMSupport, so just tweaked the previous patch, and