similar to: [LLVMdev] CrashRecoveryContext on Windows

Where did getBacktrace go? I cant find any changes about it except for it simply disappearing after I updated from 3.8 to 4.0... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/6ca7bce9/attachment.html>

This CL is probably apropos to the issue described below.. We here in the PNaCL team are building llvm+clang using a specially bootstrapped version of llvm-gcc. Unfortunately, the configure is picking up system clang even though we force set CC and CXX during the configure process. llvm[2]: Compiling CommandLine.cpp for Release+Asserts build if clang++ -I<LLVMSRC>/include

On Fedora 17 I have installed a the binary clang package clang3.0-14. When I tried to build the latest llvm/clang from source using this binary clang I get essentially two different errors: 1) In file included from /home/fceldiener/vcs/llvm/include/llvm/Support/SwapByteOrder.h:20: /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1404:27: error: use of

Hey everyone, first of all I just wanted to say thanks :) I've been using libclang for building my own C/C++ IDE and its great. I have, however discovered a bug (which I already submitted on llvm bugzilla but I got the impression that no one reads that :)). If I try to use clang_parseTranslationUnit on this code below: int main() { return reinterpret_cast libclang crashes. This is the code

On Tue, 3 Aug 2010 23:57:05 -0700 Bill Wendling <wendling at apple.com> wrote: > Good news, everybody! > > It's that time of year again. We are going to release LLVM 2.8! I'm > taking over for Tanya to give her a much needed break. I can only > hope to perform as well as she has. This is my first time as release > manager, so bear with me if things don't go

As part of my effort to replace our hand-rolled mutexes with std::mutex and std::recursive_mutex, I found that many of the tests were failing on Windows after doing the replacement. One of the reasons was due to the use of a mutex in lib\Support\CrashRecoveryContext.cpp. If this mutex is an std::recursive_mutex or std::mutex, tests fail. If this mutex is a windows CRITICAL_SECTION, the tests

On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Sun, 03 Jun 2012 12:12:06 -0700 > Chris Lattner <clattner at apple.com> wrote: > > > > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > > > If I may add my two cents: > > > > > > I am planning to use LLVM as the backend for a compiler I am >

Is there a simple method for compiling a custom assertion header/call into all the LLVM libraries? I want my application to be able to handle any thrown assertions (ie; as an exception) and recover or crash gracefully. I already have a custom header in place in the application's source, however this doesn't have an effect on [most of] the already compiled lib's. -------------- next

On Mon, Jun 4, 2012 at 11:46 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >> On Sun, 03 Jun 2012 12:12:06 -0700 > >> Chris Lattner <clattner at apple.com>

On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> On Sun, 03 Jun 2012 12:12:06 -0700 >> Chris Lattner <clattner at apple.com> wrote: >> >> > >> > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: >> >

Hi Folks, I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g. Linking CXX static library ../libLLVMSupport.a cd

On Mon, Jun 4, 2012 at 1:48 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Jun 4, 2012 at 11:46 AM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski >> <justin.holewinski at gmail.com> wrote: >> > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov>

I've hit this weird compiler error when building llvm/clang $ clang --version clang version 2.9 (trunk 125254) Target: x86_64-apple-darwin10 Thread model: posix Source rev is 125326 $ make llvm[1]: Compiling APFloat.cpp for Release build llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling APSInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]:

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to

I encountered a new build failure (r227128) on my nightly build of LLVM for MinGW: FAILED: cmd.exe /c cd . && D:\MinGW\x86_64-4.9.1-release-posix-seh-rt_v3-rev0\mingw64\bin\c++.exe -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=gnu++11 -g

On Sun, 03 Jun 2012 12:12:06 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > If I may add my two cents: > > > > I am planning to use LLVM as the backend for a compiler I am > > working on. And I wholeheartedly agree with Justin that it is a > > problem, if LLVM is allowed to freely

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive

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