similar to: [LLVMdev] Proposal for GSoC project for clang front end

On Wed, 19 Mar 2008, Argiris Kirtzidis wrote: > I'd like to hear your opinions and ideas for a proposal to improve > support for C++ parsing for LLVM's clang front end. Some meta feedback: C++ support in clang is a huge project, far and away more than any mortal can get done in a summer. While it would be possible to sketch out the parser itself in the summer (providing the

On Wednesday 19 March 2008 21:27:18 Chris Lattner wrote: > On Wed, 19 Mar 2008, Argiris Kirtzidis wrote: > > I'd like to hear your opinions and ideas for a proposal to improve > > support for C++ parsing for LLVM's clang front end. > > Some meta feedback: C++ support in clang is a huge project, far and away > more than any mortal can get done in a summer. While it

Thanks for your feedback Chris, Chris Lattner wrote: > If I were going to pick, I would suggest focusing on getting simple > methods implemented, along with instance variables, etc through > -fsyntax-only. This should be a reasonable amount of work for a summer. > Something like this should work for example: > > class foo { > int X; > typedef float Z; > int

On 3/19/08, Argiris Kirtzidis <akyrtzi at gmail.com> wrote: > 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

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

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

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

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

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

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

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.

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

Ó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

Ken McMillan wrote: > 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. > Works fine here (llvm 2.5, 32 bit, gdb 6.8) Try llc

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

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'