similar to: [LLVMdev] Exception Tables in latest LLVM

Hi Yiannis, > I have been using llvm 2.8 (i know ancient history!) for a backend that i was > implementing. I have been trying to port my patches to latest llvm (svn build) > lately but i have one problem as far as the Exception Handling mechanism is > concerned. It seems that there are no Exception Tables generated any more such > as the one below: got some example bitcode for

On 09/02/2011 05:58 PM, Duncan Sands wrote: > Hi Yiannis, > >> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >> implementing. I have been trying to port my patches to latest llvm (svn build) >> lately but i have one problem as far as the Exception Handling mechanism is >> concerned. It seems that there are no Exception Tables generated

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

John, I'm still not sure what you're talking about, I have included the assembly output from two compilations, one with a user explicit catch-all, one with only an implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, as are the indexes used to reference the Action Table from the region maps. -Peter Lawrence.

Hi Yiannis, >>> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >>> implementing. I have been trying to port my patches to latest llvm (svn build) >>> lately but i have one problem as far as the Exception Handling mechanism is >>> concerned. It seems that there are no Exception Tables generated any more such >>> as the one

On Jul 28, 2011, at 2:22 PM, Peter Lawrence wrote: > John, > I'm still not sure what you're talking about, I have included the assembly > output from two compilations, one with a user explicit catch-all, one with only an > implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, > as are the indexes used to reference the Action Table from

Hi, I wanted to propose an IR extension that would allow us to support zero-cost exception handling for non-call operations that may trap. I wanted to start with loads and stores through a null pointer, and later we might extend this to div/rem/mod zero. This feature is obviously useful for implementing languages such as Java and Go which deterministically translate such operations into

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Hi all, I'm compiling LLCM IR code like this on x86-64: define linkonce ccc <16 x float> @vector_add_float(<16 x float> %a.78, <16 x float> %a.79) align 8 { entry: %result.80 = fadd <16 x float> %a.78, %a.79 ret <18 x float> %result.80 } This works really well when the vector length (16 in the above) is an integer multiple of the SSE vector

Hi, I just updated from r190763 to r191137 and started getting failures in generated assembly language when debug info is enabled. Here is the test case: // Compile and run for every target. // RUN: %ecc -g -o %t %s && %t // FAIL: %armecc -g -o %t %s && %armrun %t // FAIL: %armebecc -g -o %t %s && %armebrun %t // RUN: %i386ecc -g -o %t %s && %i386run %t // FAIL:

Interesting. File please? Thanks. On Sep 21, 2013 6:01 AM, "Richard Pennington" <rich at pennware.com> wrote: > Hi, > > I just updated from r190763 to r191137 and started getting failures in > generated assembly language when debug info is enabled. Here is the test > case: > > // Compile and run for every target. > // RUN: %ecc -g -o %t %s && %t

I'm trying to find a way to emulate a floating point instruction, say a floating point add. My understanding is that in order to do that I need to execute setOperationAction(ISD::FADD, (MVT::f32, Expand); setOperationAction(ISD::FADD, (MVT::f64, Expand); in MyTargetISelLowering.cpp, MyTargetLowering::MyTargetLowering(...). However for some reason I'm still seeing a floating point add in

On Jul 28, 2011, at 8:41 AM, Peter Lawrence wrote: > In short the problem is that there is an ambiguity between a cleanup handler having > an Action Table entry that looks like > .byte 1 ;; Type = 1 (ie #1 entry in Types Table) > .byte 0 ;; Next = 0 (ie none, ie this is the list terminator for this try-statement) > together with a corresponding Types Table entry #1 that looks

If it thinks the symbol is in the BSS section, then it should never have tried to use .comm to emit it I think. On x86 it does not try to mix and match, which is why it works. AFAIK comm symbols are regarded as having no section, rather than being bss, so I think it's a bug in whatever code printed that .comm statement. I'll look into this tomorrow. > Eric Christopher

I recently noticed a difference between the way GCC and LLVM treat sign extension for parameters and return values on x86-64. I could not find a clear answer in the x86-64 ABI [1] concerning whether parameters should be sign extended by the caller or callee and similarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division

On Jul 27, 2011, at 11:10 AM, John McCall wrote: > >> 4) IIUC, llvm has inherited a bug from gcc where the debugger >> cannot let the user know an exception is >> going to be uncaught until after the stack has been unwound -- >> contrary to the design intentions of the >> unwind library that most exception implementations are based on >> (with a two

Hi James, > I've been trying to get a minimal test function to work, which simply > invokes _Unwind_RaiseException with a single clean-up landing pad. > However. when I run it my personality function is not getting called - > _Unwind_RaiseException simply returns apparently doing nothing. Looking > at the x86-64 assembly output from llc, I can see this is happening >

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > I've been trying to get a minimal test function to work, which simply >> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >> when I run it my personality function is not getting called - >> _Unwind_RaiseException simply returns apparently doing nothing. Looking at

Hi, I'm investigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote: > Bill, > ooops, yes, I described the meaning of "throw(A)" backwards, I thought that might be the case. :) > but I still > think my example shows why you cannot merge LandingpadInst while > inlining because multiple filter-lists on a LandingpadInst don't make sense. > > Perhaps I'm reading your