similar to: [LLVMdev] non-enable-llvm support in llvm-gcc-4.2 issue

So, a while back I got a compile error where the assembly was missing some whitespace between a .set and the identifier and tracked it down to this simple mistake that I just verified is still in the tree: Index: lib/Target/ARM/ARMTargetAsmInfo.cpp =================================================================== --- lib/Target/ARM/ARMTargetAsmInfo.cpp (revision 48700) +++

On Dec 12, 2007, at 11:01 AM, Duncan Sands wrote: > Hi Dale, > >> No, I don't want to change the semantics of invoke, at least I don't >> think so. >> When inlining, I want the inlined throw to reach cleanup code as it >> does. >> But I want the Unwind_Resume call that ends the cleanup code to be >> replaced with a control transfer to the handler

On Thu, Oct 2, 2008 at 11:34 AM, Jay Freeman (saurik) <saurik at saurik.com>wrote: > gcc is correct. According to the ISO specification, the for-init-statement > is supposed to inject any variable names into the same declarative scope as > the condition of an equivalent restructuring of the loop in the form of a > while statement, which in turn fronts the declaration to an extra

Duncan, It would be useful to know what motivated this work -- in particular, is some organization (company, open source project team, research group, any other kind) interested in having an Ada front-end? Thanks, --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Associate Professor, Computer Science E-MAIL: vadve at cs.uiuc.edu Siebel

I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

Jay Freeman (saurik) wrote: > Those rules only apply to if and switch statements. (Yes, this is insane, > but true.) The entire section you are quoting from, 6.4, is titled > "Selection statements [stmt.select]", which specifically covers these two > cases. A for is an iteration statement, not a selection statement. > See 6.4p2: "The rules for conditions apply

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

Those rules only apply to if and switch statements. (Yes, this is insane, but true.) The entire section you are quoting from, 6.4, is titled "Selection statements [stmt.select]", which specifically covers these two cases. A for is an iteration statement, not a selection statement. So, if you read 6.5.3p1 (which is actually about for statements) it states that a for loop is rewritten

Jay Freeman (saurik) wrote: > gcc is correct. According to the ISO specification, the for-init-statement > is supposed to inject any variable names into the same declarative scope as > the condition of an equivalent restructuring of the loop in the form of a > while statement, which in turn fronts the declaration to an extra scope that > surrounds the /entire/ loop construct.

Ah, interesting, have not ran across that before (as I always strive to never use the same name as any scope previously), but rather interesting that GCC gets it wrong while VC++ gets it right, kind of a switch. And yes, that switch I mentioned is for VC6 style in VC7.1 (what I use), you have to switch it to make it conformant, nice to hear VC8 does it correctly by default now. On Thu, Oct 2,

When compile 403.gcc, there are link errors. 1) environment 1.1) OS Linux gnode107 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux *1.2) The default GCC compiler is * gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for

Hi, I was wondering whether anyone has managed to compile the LLVM libraries to run on iPhone? After compiling and installing the iPhone toolchain on MacBook running Leopard (10.5.2). I run configure In the llvm2.3 directory: ./configure –host=arm-apple-darwin –target=arm-apple-darwin –enable-optimized –enable-targets=arm I run make, including an override for TBLGEN (because I obviously

Taken from tools/llvmc2/CompilationGraph.cpp: ... for (typename C::const_iterator B = EdgesContainer.begin(), E = EdgesContainer.end(); B != E; ++B) { const Edge* E = B->getPtr(); ... MS C++ compiler (VS 2008) gives: ... CompilationGraph.cpp ..\..\..\llvm\tools\llvmc2\CompilationGraph.cpp(58) : error C2371: 'E' : redefinition; different basic types

gcc is correct. According to the ISO specification, the for-init-statement is supposed to inject any variable names into the same declarative scope as the condition of an equivalent restructuring of the loop in the form of a while statement, which in turn fronts the declaration to an extra scope that surrounds the /entire/ loop construct. VC++ seems to be scoping the variables as if they were

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that

In trying to package up LLVM for Debian, it appears that x86_64 is no longer a supported architecture -- so, my first question is, is that correct? Best I can tell, the only thing that's supposed to work for x86_64 is the C backend. For Debian, I need to build everything from scratch. When trying to build llvm-gcc4 from source, though, I get part way through the build and am told that

Hi Dale, > No, I don't want to change the semantics of invoke, at least I don't > think so. > When inlining, I want the inlined throw to reach cleanup code as it > does. > But I want the Unwind_Resume call that ends the cleanup code to be > replaced with a control transfer to the handler (or cleanup) in the > calling > function, i.e. the inliner needs to know

On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int

Hello openssh-unix-dev list members, This is related to my previous post, but I need to ask specific questions. I'm building openssh with iPhone Toolchain (http://wikee.iphwn.org/howto:toolchain_on_leopard_aspen) for iPhone 2.1 firmware. This is not an iPhone mailing list, but probably anyone with deep knowledge of openssh could give a hint. So this is what I do: 1. I patch the files using