similar to: [LLVMdev] New llvm-db ?

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> How does updating the CMake produced VC++ project files work ? >> I mean: >> >> -I have CMake produce VC++ project files >> -Compile the solution >> -Do a svn update and pick up a couple of files >> -Have CMake produce new project files >> -Now, do I have

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > How does updating the CMake produced VC++ project files work ? > I mean: > > -I have CMake produce VC++ project files > -Compile the solution > -Do a svn update and pick up a couple of files > -Have CMake produce new project files > -Now, do I have to rebuild the entire solution again ? AFAIK, it should do the right

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > I gave it a try and unfortunately it doesn't seem practical to use > CMake-produced VC++ projects. Every time you run CMake so that the VC++ > projects include new files, the entire solution gets rebuilt. I recall some discussion about the behavior you describe on the cmake ml, but can't find it right now. IIRC, once

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

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> I gave it a try and unfortunately it doesn't seem practical to use >> CMake-produced VC++ projects. Every time you run CMake so that the VC++ >> projects include new files, the entire solution gets rebuilt. >> > > I recall some discussion about the behavior you

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

Hi all, I'd like to hear your opinions and ideas for a proposal to improve support for C++ parsing for LLVM's clang front end. Goal: Improve clang's C++ support. The scope of the project will be limited to C++ parsing, not code generation (I think the timeframe of a GSoC project and the complexity of C++ doesn't allow full C++ support to be developed). C++ parsing support

Óscar Fuentes wrote: > Done. > > As this is a major change, if the build fails after the update try again > starting from a empty build directory. > Hey, it works great now, thanks! I have some more requests: -Is it possible to also have the include files in the projects ? -Can llvm-config or something like it be used to sort the dependencies of the executables ? -Could you

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

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.

Argiris Kirtzidis wrote: > > ... > > Try > llc -disable-fp-elim gdb1.bc > > Thanks, I would never have guessed that :-). Are there any other optimizations that are harmful to debug info that I should know about? Thanks -- Ken -- View this message in context: http://www.nabble.com/problems-with-dwarf-gdb-tp23033690p23049871.html Sent from the LLVM - Dev mailing list

I have updated "DataTypes.h.in", could you do a svn update and see if it works ? -Argiris Óscar Fuentes wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > > >>> It appears the Windows build has regressed over the past week. >>> >>> The build fails quite early (during the "Performing TableGenStep" >>> phase).

How does updating the CMake produced VC++ project files work ? I mean: -I have CMake produce VC++ project files -Compile the solution -Do a svn update and pick up a couple of files -Have CMake produce new project files -Now, do I have to rebuild the entire solution again ? -Argiris

Óscar Fuentes wrote: > All the headers in include/llvm? Or just those local to each library? > All the headers. It's a pain to manually update the project files but it will be a bigger pain trying to use them without the include files.. included. > >> -Could you please also add Clang to the CMake system ? >> > > So far we are having sunny days here.

Hi Argiris, It was for example the project TableGen, llvm-dis... I saw it under Properties/Linker/Command Line And the output is also: Linking... Starting pass 1 LINK : fatal error LNK1181: cannot open input file '..\configure\configure\configure.lib' Build log was saved at "file://d:\Studium\Diplom\Download\llvm-2.3\win32\TableGen\Win32\Release\Bui ldLog.htm" TableGen - 1

I see. Here's another interesting issue: (gdb) b gdb1.c:4 No line 4 in file "gdb1.c". (gdb) step foo () at /home/mcmillan/projects/impact2/test//gdb1.c:4 4 x++; (gdb) You can see that I can step to line 4, but I can't set a breakpoint there. (I used -disable-fp-elim in the compilation). Have you seen this before? Thanks -- Ken Dale Johannesen wrote: > > > On

Hello, Argiris > Any ideas? 1. Make sure, that you don't mix dwarf and stabs debug information. AFAIR, this can really mess the things 2. It can be, that debug information emitted is not correct. This is known open problem. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Le Anh Quang wrote: > Hi, > but on some other project, they require "configure.lib". What is this one ? > Thanks Hi Le Anh, What project are you talking about, and how did you determine that it requires "configure.lib" ? AFAIK, all LLVM projects have dependency on the configure project but this is only so that some include files are created, no

Well... $ ~/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/llvm-gcc -g gdb1.c -o gdb1 /tmp/ccbAj8x9.s: Assembler messages: /tmp/ccbAj8x9.s:35: Error: suffix or operands invalid for `push' /tmp/ccbAj8x9.s:44: Error: suffix or operands invalid for `pop' /tmp/ccbAj8x9.s:56: Error: suffix or operands invalid for `push' /tmp/ccbAj8x9.s:65: Error: suffix or operands invalid for `pop'

Anton Korobeynikov wrote: > 2. It can be, that debug information emitted is not correct. This is > known open problem. > The attached patch fixes the problem with the line information. For the "AT_stmt_list" attribute of the compilation unit entry, DWARF-2 specification says: > A DW_AT_stmt_list attribute whose value is a reference to line number > information for