similar to: [LLVMdev] Reminder: 3.6 branch is coming

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

On 10 Jan 2015, at 17:35, Dimitry Andric <dimitry at andric.com> wrote: > > It looks like the interpretation of what "__STDC_MB_MIGHT_NEQ_WC__" means differs between the llvm developers and the FreeBSD developers. I'm not sure what a good solution is. I've just read the relevant parts of the C11 spec, and it's not really clear to me what the 'basic

Tried a small test just now to see how exception handling on Windows is getting on, and it seems to work except for one thing. clang-cl /EHsc (the Microsoft compiler option to enable exceptions) doesn't do anything; they remain disabled. However, -Xclang -fcxx-exceptions succeeds. Is this a bug in the handling of compatibility options or am I missing something? -------------- next part

On 12 Jan 2015, at 08:07, Dimitry Andric <dimitry at andric.com> wrote: > > > On 15 Oct 2014, at 19:42, Richard Smith <richard at metafoo.co.uk> wrote: >> On 15 Oct 2014 05:12, "Ed Schouten" <ed at 80386.nl> wrote: > ... >> The test case in the LLVM tree is invalid and should be discarded. It >> erroneously assumes that the encoding of

I'm trying to use Clang on Windows to compile C++ to bitcode and then to an executable (with a view to carrying out some experiments on whole program optimization of the bitcode). When I use clang.exe, even with -D_HAS_EXCEPTIONS=0 -fms-compatibility -fms-extensions, I get errors: main-621e97.o : error LNK2019: unresolved external symbol _Unwind_Resume referenced in function main

Hi everyone, I've been wondering how to correctly build clang/LLVM for the AVR target architecture. Unfortunately documentation is very scarce (or outdated or I didn't find it) and while I've been able to build clang/LLVM for AVR I'm still falling short of compiling an actual binary for the MCU. Here are the steps I've undertaken so far: git clone

Hi Jack, Are you packaging all the static libraries that lld produces as part of the package ? PS : When I build on x86_64, I only get a 9M image for lld. Thanks Shankar Easwaran On 11/20/2013 9:15 AM, Jack Howarth wrote: > When lld-3.4 is added to the tools directory of the llvm source tree > as lld, the resulting cmake build produces a huge number of static libs and > bloats

Hi, Thanks for the quick reply again. > On Thu, Dec 15, 2011 at 1:17 PM, David Fang <fang at csl.cornell.edu> wrote: >> Hi, >> >> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and >> have the following test results to share. >> Summary below, full log at: >>

Hi, I apologize if I'm posting this to the wrong list; if this is the case, please let me know. For some time now, I've been trying to get SEH exception handling to work in LLVM MCJIT (x64). While reading up on LLVM 3.8, I decided to pick it up again, because a lot has changed which simplifies things greatly. As a toy project, I'm attempting to catch an exception that's thrown

Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4

On Fri, Mar 4, 2016 at 5:50 PM, Yuanfeng Peng <yuanfeng.jack.peng at gmail.com> wrote: > Hi Jingyue, > > My name is Yuanfeng Peng, I'm a PhD student at UPenn. I'm sorry to bother > you, but I'm having trouble with gpucc in my project, and I would be really > grateful for your help! > > Currently we're trying to instrument CUDA code using LLVM 3.9, and

Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],

When lld-3.4 is added to the tools directory of the llvm source tree as lld, the resulting cmake build produces a huge number of static libs and bloats the overall package from... -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 llvm34_3.4-0_darwin-x86_64.deb to -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 llvm34_3.4-0_darwin-x86_64.deb Is this a known issue with the initial release of

Thank you for both of your input. Yes, I try to cross-compile for AVR, the simple ATMEGA328P used in every Arduino Uno. My main motivation being that I hope to be able to use a couple of STL containers, <functional> and <type_traits> on the MCU. Not sure though if this can be reached by going via the clang route. Getting back to the compilation: when I run clang with both both

On 18 July 2012 15:24, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > I'm not sure how to interpret the above output, but I don't understand > why if say -triple armv4t-none--gnueabi . Ok, we're getting there... ;) I think these errors are due to Clang not finding the libraries/includes/etc for the target you're building. If you have

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

Hi! Quick question - do you know if recent commits could cause this error, or I should go to bisect/debug this? Do we have tests that check that -gsplit-dwarf succeeds (i.e. compile and link step work)? $ cat a.cc int foo(int x) { return x + 1; } int main() { return foo(42); } $ ./bin/clang++ -gsplit-dwarf a.cc /tmp/a-005b1a.o(.debug_pubnames+0x6): error: undefined reference to

Hey Jingyue, Thanks for being so responsive! I finally figured out a way to resolve the issue: all I have to do is to use `-only-needed` when merging the device bitcodes with llvm-link. However, since we actually need to instrument the host code as well, I encountered another issue when I tried to glue the instrumented host code and fatbin together. When I only instrumented the device code, I

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,