similar to: [LLVMdev] type-system-rewrite branch near landing

> 1. Clang - Jay, do you have a patch for this? Yes. It's good enough to build most of LLVM+Clang, except for a couple of files. But I'm running out of time and expertise to be able to fix the remaining bits. Some specific concerns: 1. Many Objective-C(++) tests fail, because they use implicitly defined structs for various ObjC runtime data structures; the ASTConsumer

On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote: >> 1. Clang - Jay, do you have a patch for this? > > Yes. It's good enough to build most of LLVM+Clang, except for a couple > of files. But I'm running out of time and expertise to be able to fix > the remaining bits. Some specific concerns: > > 1. Many Objective-C(++) tests fail, because

> 1. Clang - Jay, do you have a patch for this?  Can you create a branch of the clang repo or send an updated version of the patch to the list? I've created a clang type-system-rewrite branch and committed all my purely mechanical changes: de-constifying llvm::Types as necessary, and using the new llvm::StructType::createNamed/setBody to create the "implicit" structs used by

>> 1. Many Objective-C(++) tests fail, because they use implicitly >> defined structs for various ObjC runtime data structures; the >> ASTConsumer HandleTagDeclDefinition callback is never called for these >> structs, which means that I don't bother to lay them out, so they only >> ever get an opaque LLVM type. Then we get assertion failures when >>

>>  ~/svn/llvm-project/llvm/branches$ svn up >>  svn: Server sent unexpected return value (403 Forbidden) in response >> to REPORT request for '/svn/llvm-project/!svn/vcc/default' > > I think that explicitly returns Forbidden just to avoid the strain on > the server; if you have any write access, you should have write access > to everything. Off topic, but

On 7 July 2011 18:41, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote: >> 2. Even some simple C cases fail, e.g.: >> >> struct S; >> extern struct T { >>  struct S (*p)(void); >> } t; >> struct S { int i; }; >> void g(void) { >>  t.p(); >> } >>

Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.

> ... and it's in.  Please let me know if you see any problems. My clang self-hosted build (Release+Asserts on Release+Asserts, Linux x86_64) fails with: make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: typename

Hi, My svn working copy mirrors the layout of the whole svn repository, from llvm-project downwards, so I have: ~/svn/llvm-project/ ~/svn/llvm-project/llvm/ ~/svn/llvm-project/llvm/trunk/ # lots of stuff in here ~/svn/llvm-project/cfe/ ~/svn/llvm-project/cfe/trunk/ # and lots of stuff in here (and likewise for test-suite, llvm-gcc-4.2 and dragonegg) This is nice because I can do "svn

On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be

Jay Foad wrote: >> ... and it's in. Please let me know if you see any problems. > > My clang self-hosted build (Release+Asserts on Release+Asserts, Linux > x86_64) fails with: > > make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' > llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build > clang:

On Jul 9, 2011, at 12:35 AM, Chris Lattner wrote: > FYI, the type-system-rewrite branch is landing tomorrow morning, in mainline llvm, llvm-gcc and clang. I don't have updates, so dragonegg will have to remain broken until someone can fix it (the changes aren't too terrible, llvm-gcc is a good template). > > If you're interested in an early preview, the type-system-rewrite

FYI, the type-system-rewrite branch is landing tomorrow morning, in mainline llvm, llvm-gcc and clang. I don't have updates, so dragonegg will have to remain broken until someone can fix it (the changes aren't too terrible, llvm-gcc is a good template). If you're interested in an early preview, the type-system-rewrite branch contains the code for llvm and clang. I sent the llvm-gcc

So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not

On 6 August 2011 23:05, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils > issue on linux x86-64 > Has anyone seen anything like this? Yes, it looks like this: http://sourceware.org/bugzilla/show_bug.cgi?id=12887 I think switching from ld to gold might be an effective work-around. Jay.

FYI, this turned out to be an error of omission in LLDB in SymbolFileDWARF, because the case of a non-defining external (i.e. a static member variable) wasn't being handled with a variable lookup to dig up the location. I'll put a patch together for lldb-commits, - Ashok From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Thirumurthi, Ashok

On Jul 12, 2011, at 5:04 AM, Vitaly Lugovskiy wrote: > Hi Chris, > > What's a new way of building recursive types (with C bindings), once > RefineType had been removed? And what's an exact reason for getting > rid of the opaque types - I could not find a relevant discussion in a > mailing list. Hi Vitaly, I didn't add this API, because I'm not very familiar

I'm getting a lot of errors from svn like this: svn: REPORT request failed on '/svn/llvm-project/!svn/vcc/default' svn: REPORT of '/svn/llvm-project/!svn/vcc/default': Could not read response body: Secure connection truncated (https://llvm.org) I've now been checking out llvm-gcc for two days. Is there a problem with the server? I don't have this issue with other

FOR IMMEDIATE RELEASE Puerto Escondido, Mexico, April 1st, 2010: Digium launches Asterisk VCC (TM) - a new virtual communication platform for enterprises, the public sector and the home. =========================================================== Asterisk 1.8 will contain a stunning new technology for all Asterisk users world- wide - virtual communication clouds or VCC (TM). With this

It's nice to see that the OS where CentOS gets its sources from also experiments the same error! I have been very busy lately so I haven't had the time to deal with the problem, probably later this week or early next week. As soon as I find something Ill let you know. Hopefully you'll do the same if you come across the solution first. PS. Forwarding this message to the mailing