similar to: [LLVMdev] a quick typo in the ARM LLVM backend

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>

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.

There seems to be a bunch of code for making certain that gcc still works even if --enable-gcc isn't used, so I'm assuming that it's at least supposed to be a supported configuration, and hence this issue that I found should probably be looked at: If you compile llvm-gcc-4.2 _without_ --enable-gcc, and then try to compile the following program, you get a rather nasty RTL error.

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

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

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

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

Fair enough, you win this round. ;P (Which actually makes me happy as that makes things a lot more consistent and sensible.) -J -------------------------------------------------- From: "Argiris Kirtzidis" <akyrtzi at gmail.com> Sent: Thursday, October 02, 2008 12:32 PM To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] MS C++ gives

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

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,

Hi, I need some help improving this ugly code I wrote. I would like to shift forward a zoo object, matrix, ts, or list by "shift" items (default 1) and fill the holes with 0's. The code below works, but it looks ugly. I could write a function lag.zerofill() which calls the two functions below depending on the class() of the item passed in, but that feels very unlike R. What is

Hi there- What''s the easiest/most efficient way to perform a zerofill in Ruby? i.e. Given the value ''val'', I would like to do something like: val = 43 puts val.zerofill(8) ---> "00000043" gsub? sprintf of some sort? Jake -- Posted via http://www.ruby-forum.com/.

Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this

On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute

On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > > This seems counter intuitive to me, I can understand that C assigned that >> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >> there is explicitly a common linkage attribute to get that behavior. Nothing >>

On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > >>> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage

On Fri, May 7, 2010 at 10:14 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that