similar to: [LLVMdev] Turning on exception handling codegen

On Fri, 24 Aug 2007, Duncan Sands wrote: > Right now llvm-gcc generates exception handling intrinsics, > but actual eh codegen (--enable-eh) is turned off. On > x86-linux, turning it on generates no new failures in the > testsuite, Woo hoo! > The problem is likely to be PPC which claims to support eh but doesn't > support it completely yet AFAIK. I suggest setting >

On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > Hi Bill, > >> This is a (very) rough patch to fix building LLVM with exceptions on >> PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" >> on the specific target, which is where I think it should go. > > I don't like it. LLVM has plenty of features that are not supported > on

On Aug 28, 2007, at 11:35 PM, Chris Lattner wrote: > On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > >>> This is a (very) rough patch to fix building LLVM with exceptions on >>> PPC Darwin. Basically, it puts the burden of adding the "--enable- >>> eh" >>> on the specific target, which is where I think it should go. >> >> I

Hi Bill, > This is a (very) rough patch to fix building LLVM with exceptions on > PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" > on the specific target, which is where I think it should go. I don't like it. LLVM has plenty of features that are not supported on all targets, why should it be the responsability of llvm-gcc to manage this particular

Hi all, This is a (very) rough patch to fix building LLVM with exceptions on PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" on the specific target, which is where I think it should go. If this is okay, then I can clean the patch up and submit it. -bw Index: gcc/llvm-backend.cpp =================================================================== ---

On 8/24/07, Chris Lattner <sabre at nondot.org> wrote: > > so how about turning it on? > > It sounds good, but I'm concerned about darwin/x86. Bill, can you see how > well darwin/x86 is doing these days? If there are no regressions from > turning this on by default, we should do it. :) > I'm assuming that this is 4.2? :-) I'll give it a try. -bw

On 24 Aug 2007, at 22:11, Duncan Sands wrote: > Hi Bill, > >> I'm trying it on 4.0. On 4.2, I'm getting this problem during >> bootstrapping: >> >> ccAMeZbg.s:111:non-relocatable subtraction expression, >> "___gxx_personality_v0" minus "L0" >> ccAMeZbg.s:111:symbol: "___gxx_personality_v0" can't be undefined

Hi Bill, > I'm trying it on 4.0. On 4.2, I'm getting this problem during bootstrapping: > > ccAMeZbg.s:111:non-relocatable subtraction expression, > "___gxx_personality_v0" minus "L0" > ccAMeZbg.s:111:symbol: "___gxx_personality_v0" can't be undefined in a > subtraction expression this is the darwin assembler that barfs, right? It

Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as

Hi Duncan, > > I'm trying it on 4.0. On 4.2, I'm getting this problem during bootstrapping: > > > > ccAMeZbg.s:111:non-relocatable subtraction expression, > > "___gxx_personality_v0" minus "L0" > > ccAMeZbg.s:111:symbol: "___gxx_personality_v0" can't be undefined in a > > subtraction expression > > this is the

Chris would like to turn on -enable-eh rather than -enable-correct-eh- support in the llvm testsuite for those targets that support it. The following patch is intended to turn it on for x86 and ppc. Anton, Duncan, are you OK with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: mf.patch Type: application/octet-stream Size: 669 bytes Desc: not

On 8/24/07, Bill Wendling <isanbard at gmail.com> wrote: > On 8/24/07, Chris Lattner <sabre at nondot.org> wrote: > > > so how about turning it on? > > > > It sounds good, but I'm concerned about darwin/x86. Bill, can you see how > > well darwin/x86 is doing these days? If there are no regressions from > > turning this on by default, we should

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hi Dale, > Chris would like to turn on -enable-eh rather than -enable-correct-eh- > support in the llvm testsuite for those targets that support it.  The   > following patch is intended to turn it on for x86 and ppc.  Anton,   > Duncan, are you OK with this? yes, though see below. > Chris would also like to discuss renaming the EH command line   > options, and I have to agree

Exception handling in LLVM is broken. It's as simple as that. We can simulate exception handling in most cases, but we cannot handle all cases. (For instance, SingleSource/UnitTests/ObjC/exceptions.m in our testsuite doesn't work on ARM at anything optimization level above -O0.) And there's no way to coerce it to work with our current EH scheme. We don't follow the exception

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,

Hi John, On 07/12/10 01:01, John McCall wrote: > On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote: >> The poor interaction between exception handling and inlining in LLVM is one of >> the main motivations for the new exception handling models proposed recently. >> Here I give my analysis of the origin of the problem in the hope of clarifying >> the situation. > >

Hi, I'm using the release version of llvm 2.6. In the llvm/projects/test-suite directory, there are several tests that are commented out from running, or not running via a define statement. In particular, I am inquiring about the status of the EH tests since some tests seem to be enabled to run by default, but some aren't. From looking at your tests, I've noticed the following: