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

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

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

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

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

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 > >

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:

Dale, > Works for me on x86-64 Darwin, fwiw. That looks pretty strange. Ok, it can work for small testcases, but will surely fail when you try to use for something more real. Currently it at least lacks information about frame moves. So, every invoke, which needs to restore call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm

Thank you, Reid. I have applied tha patch to ltdl.c ltdl.h. The problem still exists. I looked up the symbol on libLLVMCore.a, and found three U-entries and one T-entry. However, the Darwin linker is not able to find the T-entry. Any idea? pollux:~/test jingyu$ opt -load /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help Error opening