similar to: 3.9 regression with legacy static assert macros (bad type resolution)

> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind: > > #define COMPILE_TIME_ASSERT( expr ) \ > extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( (

It already shipped AFAIK: http://releases.llvm.org/download.html — Mehdi > On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Can we still check patches into 3.9.1? > >> On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: >> >> >>> On Dec 23, 2016, at 11:17,

> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote: > > >> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind: >> >> #define

Can we still check patches into 3.9.1? > On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: > > >> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote: >> >> >>> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>

+Tom : is there a plan for a 3.9.2? — Mehdi > On Dec 27, 2016, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > It already shipped AFAIK: http://releases.llvm.org/download.html > > — > Mehdi > >> On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Can we still check patches into

There's a regression in AMDGPU which would be nice to get resolved, see: https://bugs.freedesktop.org/show_bug.cgi?id=99078 https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620?comments=all I think it's reasonably low-risk to back-port AMDGPU: Reduce the duration of whole-quad-mode AMDGPU: Do not clobber SCC in SIWholeQuadMode since they've been in trunk and

Hi Nick! In r207467 you added code(libunwind: DwarfInstructions.hpp): assert(lastReg <= (int)cieInfo.returnAddressRegister && "register range does not contain return address register"); for (int i = 0; i <= lastReg; ++i) { ..... else if (i == (int)cieInfo.returnAddressRegister) There is misprint here: lastReg should be >=

Hello, We have been investigating a crash in our application that may be related to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack. Here is what the stack trace looks like on MacOSX 10.6 : 0 libSystem.B.dylib

This may be bogus, but do you have: llvm::JITExceptionHandling = true; for the code that generates the dynamic code? It has been a while, but I don't recall what will happen when dynamic code, generated with jit exception handling turned off, invokes libraries which in turn try to unwind the stack via the libunwind api. However given that you say the code works with 2.8, my concern

I've started the process of bringing LLVM's libunwind into the FreeBSD base system[1]. As part of that process we've tested building the approximately 25,000 third party software packages in the FreeBSD ports collection against a modified FreeBSD with libunwind included[2]. Of course, I wouldn't expect much in the way of build failures -- I'd expect any issues to be largely

Hi All, We recently migrated to llvm 9 from gcc -7 and found that the stack usage is more like 5K in the below function getInfoFromDwarfSection() @ line : 1484 <https://github.com/llvm-mirror/libunwind/blob/master/src/UnwindCursor.hpp#L1484> With our analysis and found that "typename CFI_Parser<A>::PrologInfo prolog" local data is taking up almost 4K space. So we

This post might be a bit off topic but I'm hoping there's someone here that can help me. I'm working on implementing support for the Objective-C ABI in the D programing language. I've based my work on the work made by another developer a couple of years ago. Most of the code is already in place and I'm now trying to make sure everything works after the merging the latest

The latest TOT of libunwind fails for me when I build UnwindRegistersSave.S for the Mips. My copy of clang uses a 2.25 binutils Mips assembler. This is the message I get: "/home/rich/ellcc/bin/mips-elf-as" -o /tmp/UnwindRegistersSave-a2c974.o -EL /tmp/UnwindRegistersSave-545450.s src/UnwindRegistersSave.S: Assembler messages: src/UnwindRegistersSave.S:99: Error: opcode not

Hello. I was trying to compile https://github.com/llvm/llvm-project/tree/master/libunwind using: - MSVC - Clang I wasn't able to configure this project for using MSVC (directly or via clang-cl): >cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libunwind --