search for: fcxx

...tions/-fno-exceptions controls whether we generate code that > copes with exceptions passing through it. > Right. Landing pads, cleanups, etc. We'll need those for emitting the EH tables, but not the unwind tables, so for this particular discussion, we don't need to worry. > -fcxx-exceptions/-fno-cxx-exceptions controls whether we allow exception > constructs in C++ code (throw, catch, try) and whether we validate > exception specifications (both during compilation and at runtime). > -fobjc-exceptions/-fno-objc-exceptions controls whether we allow > exception c...

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 -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150902/fd351e3c/attachment.html>

Reminder: The plan is to create the 3.6 branch next week, on 14 January. Please help get the release notes and other documents updated. For example, both the LLVM [1] and Clang [2] release notes look pretty empty. Also, if you'd like to volunteer to be a release tester, please let me know. Cheers, Hans 1. http://llvm.org/docs/ReleaseNotes.html 2.

...le EH today, we'll disable Dwarf stack unwinding altogether. But we also need a final solution for problem 4 below before we start. 4. Clang EH control There are a number of Clang/LLVM options to control exception handling: * -fno-excetpion (enable/disable EH on C++ mode, off in C mode) * -fcxx-exception (no idea, is it objC++ specific? does it control tables in any way?) * -funwind-tables (forces uwtable attribute?) * -arm-disable-ehabi (ARM specific bogus flag) Those options are not always completely exclusive, and they damage different parts of the compilation process (as seen recen...

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

...mconstructor-aliases -target-cpu atmega328p -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/local/lib/clang/11.0.0 -fdeprecated-macro -fdebug-compilation-dir /home/alex/tmp/clang-avr -ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o main.o -x c++ main.cpp clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/l...

...} catch (...) { return 0; } } -- My first attempt was to run LLC to simply create the code for me. Basically the steps I took were: - clang -std=c++14 -O3 -emit-llvm -S -fexceptions -fms-compatibility -fcxx-exceptions test.cpp - llc -march=cpp -o test_exceptions.cpp test.ll Unfortunately this won't work; LLC doesn't seem to support this and will exit with an error: 'LLVM ERROR: Bad constant'. My second attempt was to simply create the CPP code myself and emit the same IR code that cl...

...uot;-fdeprecated-macro" "-fno-dwarf-directory-asm" "-fdebug-compilation-dir" "/usr/local/google/home/jingyue/Work/cuda" "-ferror-limit" "19" "-fmessage-length" "205" "-pthread" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-o" "/tmp/axpy-a88a72.s" "-x" "cuda" " axpy.cu" "/usr/local/cuda/bin/ptxas...

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

...mconstructor-aliases -target-cpu atmega328p -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/local/lib/clang/11.0.0 -fdeprecated-macro -fdebug-compilation-dir /home/alex/tmp/clang-avr -ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o main.o -x c++ main.cpp > clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target x86_64-unknown-linux-gnu > #include "..." search starts here: > #include <...> search starts her...

...t; "-fdeprecated-macro" "-fdebug-compilation-dir" "/llvm_build_clang" "-ferror-limit" "19" "-fmessage-length" "211" "-mstackrealign" "-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-slp" "-o" "/tmp/a-b567ef.o" "-x" "c++" "a.cc" "-split-dwarf-file" "a.dwo" "/usr/bin/objco...

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 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 *** ^C blaikie at blaikie-linux:/tmp/dbginfo$ cat crash_on_invalid.cpp // RUN: %clang_cc1 -fexcept...

.../mahesha/LLVM/install/lib/clang/9.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilat ion-dir /home/mahesha/Scratch -ferror-limit 19 -fmessage-length 211 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o hello.ii -x c++ hello.cpp -faddrsig clang -cc1 version 9.0.0 based upon LLVM 9.0.0svn default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/...

..._wrapper.h" "-O3" "-fdeprecated-macro" "-fdebug-compilation-dir" "/mnt/wtf/workspace/cuda/gpu-race-detection" "-ferror-limit" "19" "-fmessage-length" "291" "-pthread" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-vectorize-loops" "-vectorize-slp" "-o" "axpy-host.o" "-x" "cuda" "tests/axpy.cu" "-fcuda-include-gpubinary" "axpy-sm_30.fatbin"...

...-isysroot /home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/ -fmodule-cache-path /var/tmp/clang-module-cache -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /home/emitrax/programming -ferror-limit 19 -fmessage-length 106 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/testReference-IcBmdF.s -x c++ testReference.cpp clang -cc1 version 3.2 based upon LLVM 3.2svn default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-n...

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

...lude -internal-externc-isystem /home/walsimou/embtoolkit.git/sysroot-armel-linux-arm920t/usr/include -std=c++11 -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /home/walsimou/embtoolkit.git -ferror-limit 19 -fmessage-length 212 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.ii -x c++ test.cpp clang -cc1 version 3.2 based upon LLVM 3.2svn default target armel-unknown-linux-gnueabi ignoring nonexistent directory "/home/walsimou/embtoolkit.git/sysroot-armel-linux-arm920t/usr/local/include...

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

...quot; >> "-fdeprecated-macro" "-fdebug-compilation-dir" >> "/mnt/wtf/workspace/cuda/gpu-race-detection" "-ferror-limit" "19" >> "-fmessage-length" "291" "-pthread" "-fobjc-runtime=gcc" "-fcxx-exceptions" >> "-fexceptions" "-fdiagnostics-show-option" "-vectorize-loops" >> "-vectorize-slp" "-o" "axpy-host.o" "-x" "cuda" "tests/axpy.cu" >> "-fcuda-include-gpubinary" &q...