search for: identifierinfos

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!

On 12/21/2016 5:01 AM, Umesh Kalappa via llvm-dev wrote: > To context was , > > Basic requirement was to append extra string to the decl name and > update all his references to the updated name. , > > So we are constructing the DeclarationName instance as stated below > code snap. > and from DeclarationName instance ,we are constructing the > DeclarationNameInfo

To context was , Basic requirement was to append extra string to the decl name and update all his references to the updated name. , So we are constructing the DeclarationName instance as stated below code snap. and from DeclarationName instance ,we are constructing the DeclarationNameInfo and same info used to create decl spec with FunctionDecl::Create () . Question is , How do ,someone

Hi everyone, TL;DR: With current pending patches applied in compiler-rt and llvm, and trunk clang, you can build your application with XRay tracing enabled on Linux with tracing enabled before main starts, and logging stops when the main thread exits. Just a quick update, I have some patches under review that when applied cleanly to LLVM and compiler-rt allows for building applications with XRay

I've hit this weird compiler error when building llvm/clang $ clang --version clang version 2.9 (trunk 125254) Target: x86_64-apple-darwin10 Thread model: posix Source rev is 125326 $ make llvm[1]: Compiling APFloat.cpp for Release build llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling APSInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]:

> > I'm not sure we would want to store the MCInst(s) in the AST. After we're > done with semantic checking and we've created the IR representation (with > inputs, outputs, clobbers, constraints, etc.), I don't think there's a > reason for the MCInst(s) to persist. > I was assuming that MCInst would already provide a lot of the needed information, like

Hi All, We have populated info in the Clang Sema i.e class Sema (include/clang/Sema/Sema.h) and like to propagate the same to Clang Codegen . Currently we are propagating through ASTContext ,where we have duplicating fields info and operation in the Sema and ASTContext . Any better way of doing the same ? Thank you ~Umesh

On Aug 6, 2012, at 1:03 PM, João Matos wrote: > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. Glad you agree. We really shouldn't be replicating information in the frontend; this very error

TB --- 2013-11-13 13:00:41 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-13 13:00:41 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-13 13:00:41 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2013-11-13 13:00:41 - cleaning the