search for: fielddecl

...)), + Alignment); } /// getFieldOffsetInBits - Return the offset (in bits) of a FIELD_DECL in a @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) { LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0)); - tree FieldDecl = TREE_OPERAND(exp, 1); - + tree FieldDecl = TREE_OPERAND(exp, 1); + unsigned LVAlign = DECL_PACKED(FieldDecl) ? 1 : StructAddrLV.Alignment; + assert((TREE_CODE(DECL_CONTEXT(FieldDecl)) == RECORD_TYPE || TREE_CODE(DECL_CONTEXT(FieldDecl)) == UNION_TYPE || TREE_CODE(...

...ABITypeSize(ElementTy)); Why these manipulations? These happens several more times below. > @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB > > LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) { > LValue StructAddrLV = EmitLV(TREE_OPERAND(exp, 0)); > - tree FieldDecl = TREE_OPERAND(exp, 1); > - > + tree FieldDecl = TREE_OPERAND(exp, 1); > + unsigned LVAlign = DECL_PACKED(FieldDecl) ? 1 : > StructAddrLV.Alignment; Can't this be expr_align(exp)? I'll stop here, because I still don't understand the need for incorporating the alignment...

...to make these builtins behave correctly with modules. Adding them was intentional :-) > > 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 fields. FieldDecl > derives (indirectly) from NamedDecl. > > Our concern is that AST processing tools expect to find a name on > fields, and the changes in question introduced fields without names. > Can they be given names, if only for AST consistency? Yes, sounds like a good idea. I’ll take a look...

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 assert unless m_a is declared: class test { static const int npos...

...M To: llvmdev at cs.uiuc.edu Cc: Greg Clayton Subject: [LLVMdev] assert when mixing static and non-static members with an external AST source 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 assert unless m_a is declared: class test { static const int npos...

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: %p...

...x34)[0x557bc13131b4] /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(+0x1649335)[0x557bc1313335] /lib/x86_64-linux-gnu/libpthread.so.0(+0x13f40)[0x7f3bc780af40] /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction18EmitLValueForFieldENS0_6LValueEPKNS_9FieldDeclE+0x8ad)[0x557bc1749abd] ``` I have an immediate workaround -- I can turn off LLVM_ENABLE_MODULES, and the crash goes away. However, I think it might be worth looking into the commit above and determining why it crashes when using `-fmodules`. At first glance, I don't see the problem, but I'...

...1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/clang/AST/ASTContext.h b/include/clang/AST/ASTContext.h index 3bdac2d..530f957 100644 --- a/include/clang/AST/ASTContext.h +++ b/include/clang/AST/ASTContext.h @@ -480,7 +480,7 @@ public: const FieldDecl *LastFD) const; // Access to the set of methods overridden by the given C++ method. - typedef CXXMethodVector::const_iterator overridden_cxx_method_iterator; + typedef CXXMethodVector::iterator overridden_cxx_method_iterator; overridden_cxx_method_iterator overridden_methods_begin(const...

...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 fields. FieldDecl >> derives (indirectly) from NamedDecl. >> >> Our concern is that AST processing tools expect to find a name on >> fields, and the changes in question introduced fields without names. >> Can they be given names, if only for AST consistency? > > Yes, sounds like...

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;> __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 fields. FieldDecl >>> derives (indirectly) from NamedDecl. >>> >>> Our concern is that AST processing tools expect to find a name on >>> fields, and the changes in question introduced fields without names. >>> Can they be given names, if only for AST consistency? >&gt...

...t not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/clang-3.0rc3.src/lib/Lex/Lexer.cpp:490:30: warning: variable ‘BeginFileLocInfo’ set but not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/clang-3.0rc3.src/lib/AST/Decl.cpp: In member function ‘unsigned int clang::FieldDecl::getFieldIndex() const’: /home/greened/src/llvm-30-rc3/clang-3.0rc3.src/lib/AST/Decl.cpp:2209:53: warning: variable ‘e’ set but not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/clang-3.0rc3.src/lib/Sema/SemaExpr.cpp: In member function ‘clang::QualType clang::Sema::CheckVectorCom...

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