search for: callexpr

This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name

...the declaration statement in the AST: |-DeclStmt 0x7ffec3869f48 <line:5:2, col:38> | `-VarDecl 0x7ffec382d680 <col:2, col:37> col:11 used f 'unsigned int' cinit | `-BinaryOperator 0x7ffec3869f20 <col:15, col:37> 'unsigned int' '+' | |-CallExpr 0x7ffec382d7e0 <col:15, col:24> 'unsigned int' | | |-ImplicitCastExpr 0x7ffec382d7c8 <col:15> 'unsigned int (*)(unsigned int)' <FunctionToPointerDecay> | | | `-DeclRefExpr 0x7ffec382d6d8 <col:15> 'unsigned int (unsigned int)' Function...

...wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function ?llvm::Value* clang::CodeGen::CodeGenFunction::EmitAMDGPUBuiltinExpr(unsigned int, const clang::CallExpr*)?: /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp:7283:39: error: *?r600_rsq? is not a member of ?llvm::Intrinsic?* return emitUnaryBuiltin(*this, E, Intrinsic::r600_rsq); ^ /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp:7289:39...

...CLANG, I want to write plugin for printing detailed information about source code such as member function, function calls etc. I have referred PrintFunctionNames.cpp, and on line documentation for it, still i am confused about implementation of functions ex:- from CallGraph.cpp i want to use VisitCallExpr(CallExpr *E) and void CallGraph::print(raw_ostream &OS), also I am getting different useful functions regarding my purpose but not getting how to override those functions, is there tutorial available regarding this. Thanks & Regards Nilesh ----------...

...;) + 172 7 clang 0x0000000001da8476 llvm::IRBuilderBase::CreateMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int, bool, llvm::MDNode*) + 278 8 clang 0x0000000000917059 clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::FunctionDecl const*, unsigned int, clang::CallExpr const*) + 13001 9 clang 0x000000000085491c clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 236 10 clang 0x0000000000879146 11 clang 0x00000000008807ae 12 clang 0x0000000000882f40 clang::CodeGen::CodeGe...

...0x0000000001da8476 > llvm::IRBuilderBase::CreateMemCpy(llvm::Value*, llvm::Value*, > llvm::Value*, unsigned int, bool, llvm::MDNode*) + 278 > 8 clang 0x0000000000917059 > clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::FunctionDecl > const*, unsigned int, clang::CallExpr const*) + 13001 > 9 clang 0x000000000085491c > clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, > clang::CodeGen::ReturnValueSlot) + 236 > 10 clang 0x0000000000879146 > 11 clang 0x00000000008807ae > 12 clang 0x000000000...

Sure this is more likely a gcc bug. However, same toolchain compiled without any problems a week ago. Also, in some organizations, upgrading gcc is very hard if not impossible. On Fri, Jul 22, 2016 at 11:11 AM, Paulo Matos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 22/07/16 20:08, Welson Sun via llvm-dev wrote: > > This is gcc4.8.0 compiling HEAD synced on