similar to: [LLVMdev] MS C++ gives error C2371 on this code while (obviously) gcc compiles it fine

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

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.

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

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

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,

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

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

Hello, I'm seeing a miscompilation from the following code: declare <4 x float>* @getPtr() define <4 x float> @func() { %rv1 = call <4 x float>* @getPtr() %rv2 = call <4 x float>* @getPtr() %rv3 = load <4 x float>* %rv1 ret <4 x float> %rv3 } The load ends up loading from the pointer returned by the 2nd function call. I traced down the problem to

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

Hi everyone, In debugging an LLVM based system with a runtime module loaded from bitcode, I ran into a strange error when trying to use getLazyBitcodeModule instead of just ParseBitcodeFile (when loading lazily I get an "Invalid CALL" during bitcode deserialization). I can't decide if this is a "bug" or just a "you shouldn't use Module/Inliner like this".

Sorry for being a newbie on the matter, but could someone explain the comment (in response to: "Considering it [LLVM] supports three other languages with try/catch clauses just fine (C++, Ada, and now, Java), I think it would be incorrect to say "it is not able to support some of the features"."): ------------------------------ The issue is that the exception handling as

Looks like LLVM support in Mono has matured to the point they're willing to advertise it: http://tirania.org/blog/archive/2009/Jul-16.html Paul PS Zoltan, sorry if I stole your opportunity to break the news :)

Being fully aware that llvmc2 is work-in-progress, here are some notes nethertheless: I already compiled llvm, but llvm-gcc was still compiling. Now I tried the new llvmc2: $ llvmc2 -opt -v main.c llvm-g++ -c -x c main.c -o /tmp/llvm_KeApik/main.bc -emit-llvm llvmc2: Can't find program 'llvm-g++' * after this, the directory /tmp/llvm_KeApik was not removed * why using /tmp at all?

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

Hi, Patrick First of all, thanks for your interest in llvmc2! Your feedback is very valuable. > The llvmc2 documentation > seems to imply that the static TableGen-based configuration will > eventually be replaced by some kind of dynamically loadable > configuration system: "At the time of writing LLVMC does not support > on-the-fly reloading of configuration..."

Hi Holger, first of all, thanks for your feedback. > I already compiled llvm, but llvm-gcc was still compiling. Now I tried the new llvmc2: > > $ llvmc2 -opt -v main.c > llvm-g++ -c -x c main.c -o /tmp/llvm_KeApik/main.bc -emit-llvm > llvmc2: Can't find program 'llvm-g++' > > > * after this, the directory /tmp/llvm_KeApik was not removed Strange, I

> If you don't care about such things - go ahead and think about sane > design proposal, how one can hook any extra scripting language for > llvmc2 without slowdown of 'main path'. This surely will be accepted! Okay, I'll focus on this. The idea is that the TableGen-based configuration would be preloaded into llvmc2, and then user-specified Lua scripts, if supplied,

This implements -dry-run for llvmc2: $ llvmc2 -dry-run main.c llvm-g++ -c -x c main.c -o /tmp/llvm_bGw2gN/main.bc -emit-llvm llc -f /tmp/llvm_bGw2gN/main.bc -o /tmp/llvm_bGw2gN/main.s llvm-gcc -c -x assembler /tmp/llvm_bGw2gN/main.s -o /tmp/llvm_bGw2gN/main.o llvm-gcc /tmp/llvm_bGw2gN/main.o -o a.out $ llvmc2 -dry-run -opt main.c llvm-g++ -c -x c main.c -o /tmp/llvm_UGZtwL/main.bc -emit-llvm opt

I've been working on some minor enhancements for llvmc2, but before I submit them, I'd like to know more about where the driver is going. Right now, llvmc2 uses TableGen at build time to statically create C++ files with hardcoded paths and command lines. The llvmc2 documentation seems to imply that the static TableGen-based configuration will eventually be replaced by some kind of

Hello: I'm loosing my mind trying to classify my outgoing messages with sieve-test (2.0.9, centos 6.4). It came to the point I think it's not even possible with a sieve script. I need to classify my outgoing messages in three folders: 1- To my department (@dept.example.com) 2- To my company (@example.com, @anyotherdept.example.com) (anyotherdept.example.com as in a way to say "any