similar to: [LLVMdev] migrating from autoconf to cmake+ninja

On Wed, Aug 27, 2014 at 4:29 PM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > prefix = CMAKE_INSTALL_PREFIX > enabled-shared = BUILD_SHARED_LIBS > targets = LLVM_TARGETS_TO_BUILD (defaults to all, or use a semicolon separated list) > disable-assertions = LLVM_ENABLE_ASSERTIONS (obviously inverted ;) > > I don't

We still have the program called "KillTheDoctor" [1] in our source tree. Its original intention was to stop requiring user interaction for crashing regression tests under Windows (infamous Dr. Watson, nowadays "[program] has stopped working" [2]), I don't think it is useful anymore. It's also a very hacky approach, as admitted in the source comment itself ("I hate

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 12:55:20 PM > Subject: Re: lld and thread over-subscription > >

On Thu, Oct 1, 2015 at 10:55 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I honestly think that the ulimit of 1024 max threads is too strict for 48 > core machine. Processes are independent each other, so it is not strange > for them to spawn as many threads as the number of cores. What's the reason > you cannot increase the limit? > Yeah, this is

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one. 2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > Do they really allways put them into Release/bin or rather $<CONFIG>/bin? > > > > -- >

That it’s faster is no surprise. Is the Release tblgen even built when you build in Debug mode? Otherwise this introduces the need to build Release before Debug. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49

Do they really allways put them into Release/bin or rather $<CONFIG>/bin? -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de |

Hi Rui, et al., I was experimenting yesterday with building lld on my POWER7 PPC64/Linux machine, and ran into an unfortunate problem. When running the regressions tests under lit, almost all of the tests fail like this: terminate called after throwing an instance of 'std::system_error' what(): Resource temporarily unavailable ... 5 libc.so.6 0x00000080b7847238 abort +

I sent out a patch for review. http://reviews.llvm.org/D10102 <http://reviews.llvm.org/D10102> -Chris > On May 28, 2015, at 9:48 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Thanks! > > 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>: > >> On May 28, 2015, at 8:37 AM, Yaron Keren

Folks, I'm having a look at LLD and I need some guidance... I know it's not production ready for x86 and ARM (the idea is to make it so). My steps: I've added it to tools/lld and ran CMake again (on x86_64) on a standard release build (static linking). It works, builds but I see one unit test error: Note: Google Test filter = InputGraphTest.Observer [==========] Running 1 test from

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

I am currently setting up my Module with module->setTargetTriple(llvm::sys::getProcessTriple() #ifdef _WIN32 + "-elf" #endif ); And my ExecutionEngine with llvm::EngineBuilder(std::move(module)) .setErrorStr(&err) .setMCPU(llvm::sys::getHostCPUName())

LLVM_DEFINITIONS used to be defined as set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS") Now it is defined as set(LLVM_DEFINITIONS " -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS") (note that it is no longer a cmake list but a string, and the string contains a leading space!) This causes CMake 3.1 to emit g++ -D

I made this change (not specifically changing from a list to a string, but changing from a hardcoded value to the value that was actually decided by cmake), and I checked that it works with cmake 2.8.12.2 which is the minimum version set in CMakeLists.txt. So if it doesn’t work with cmake 3.1/3.2 then that looks like something new that was introduced after 2.8.12.2. I’ll have a look at this

On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and > -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work. > -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker. > However, if you do not