search for: fielddecls

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

> On Feb 19, 2016, at 7:16 AM, Brad King <brad.king at kitware.com> wrote: > > On 02/18/2016 05:51 PM, Michka Popoff wrote: >> Our problem is that the AST contains some declarations which were not there before. > [snip] >> __NSConstantString and __NSConstantString_tag are now exposed. > [snip] >> Maybe someone could enlighten us about this change. >>

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

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

I created a plugin to add simple Annotations to VarDecls and FieldDecls, and write this modified AST out to a file. I notice that when I use clang to compile this file I get different code then when I use the source directly. In both cases I'm compiling with -O4. Can anyone explain this? Thanks define i32 @somefunc(i32 (i32)* %ptr) nounwind uwtable { entry: %pt...

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

Hi all, I find a bug in the VASTContext.h of the latest clang. I fixed it and commit a patch for it. As follows: >From 447d31176b513a03b253eb25ef314c2a3c0e428a Mon Sep 17 00:00:00 2001 From: Tsingray <tsingray at buildbot-slave-desktop.(none)> Date: Thu, 8 Mar 2012 22:11:54 +0800 Subject: [PATCH] fix a 'does not name a type' bug in VASTContext.h ---

On 02/19/2016 10:35 AM, Ben Langmuir wrote: >> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >> [snip] >>> __NSConstantString and __NSConstantString_tag are now exposed. >> To clarify, this is not so much about the appearance of new builtins >> but that the structure has fields with no name. Other builtin >> structures like __va_list_tag have names on their

Hi I am the maintainer of pygccxml, which uses clang/llvm and CastXML to parse c++ code. A user reported a problem with the current llvm 3.9 trunk version (I tested with r261262). Our problem is that the AST contains some declarations which were not there before. Using "clang -Xclang -ast-dump” on a c++ file, I get the following result: TranslationUnitDecl 0x8e41ab0 <<invalid

> I created a plugin to add simple Annotations to VarDecls and > FieldDecls, and write this modified AST out to a file. I notice that > when I use clang to compile this file I get different code then when I > use the source directly. In both cases I'm compiling with -O4. Can > anyone explain this? This is how clang implements annotations on local variables, t...

> On Feb 25, 2016, at 7:49 AM, Brad King <brad.king at kitware.com> wrote: > > On 02/19/2016 10:35 AM, Ben Langmuir wrote: >>> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >>> [snip] >>>> __NSConstantString and __NSConstantString_tag are now exposed. >>> To clarify, this is not so much about the appearance of new builtins >>> but

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with > more to come during the week. Please build this release candidate, > test it out

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your

Please review this patch for PR3510 (and <rdar://problem/6564697>). The bug is a failure to handle a "hole" inside an initialized structure, where the hole may be induced by a designated initializer or by alignment: http://llvm.org/bugs/show_bug.cgi?id=3510 The original code was greatly simplified by using FieldNo to index the LLVM fields and the initializer in

Good day, LLVMers! We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc3/ for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. Please keep