similar to: Multiple Inheritance with dyn_cast

Been having a bit of a problem with dyn_cast: Suppose I have a class A that inherits from two base classes, both of which support dyn_cast. In order to use dyn_cast on A, I need to do a bunch of extra work: 1) Since dyn_cast uses reinterpret_cast rather than static_cast, the pointer value won't get adjusted by the cast operation, making the pointer invalid. I end up having to redefine

On 3 May 2018, at 22:09, David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below

On Sun, Oct 23, 2011 at 10:34 PM, James Molloy wrote: > Hi, > > I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. > $ make happiness ... Updated to revision 142790. ... make[4]: Entering directory `/home/ecsardu/LLVM/build-tcclab1/tools/clang/tools/libclang' llvm[4]: Compiling

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style

Hi, I'm trying to understand how clang keeps track of which declarations are called within a translation unit and decides to codegen their definitions. DeclBase.h has a markUsed to keep track of ODR use, and I think that the decl can be found from the symbol table via ASTContext.h (for example looking up a template via GetQualifiedTemplateName -> getAsTemplateDecl -> setIsUsed ). This

Hi Vadim, which compiler are you using to to the build, what platform are you on, how did you configure LLVM, clang etc ? Ciao, duncan. On 09/09/12 03:36, Vadim Khoptynets wrote: > Hello everyone! > > After I've checked out Clang and Compiler-RT repositories, I receive this error > during compilation: > > llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build >

Hmmm... It seems like I should check out how the UseList on Value (and its child BasicBlock) work. On Tue, May 1, 2018 at 8:34 PM, Keith Wyss <wyssman at gmail.com> wrote: > Hi, > > I'm trying to understand how clang keeps track of which declarations are > called within a translation unit and decides to codegen their definitions. > > DeclBase.h has a markUsed to keep

Hi, I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. Cheers, James ________________________________________ From: Csaba Raduly [rcsaba at gmail.com] Sent: 23 October 2011 18:44 To: James Molloy Cc: Paul Berube; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] build warnings On Sat, Oct 22,

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

If I understand correctly, Operator is basically a trivial temporary object that holds some common functionality for both Instruction and ConstantExpr. It looks to me like Operator is doing something illegal though. For example, in this member function of class Operator (in include/llvm/Operator.h): /// getOpcode - Return the opcode for this Instruction or ConstantExpr. /// unsigned

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

On Nov 12, 2010, at 5:57 PM, Óscar Fuentes wrote: >> Could someone >> please explain why I should use dyn_cast instead of dynamic_cast? (I >> thought all classes have v-tables...) Thanks, > > For reducing executable size, LLVM builds with RTTI disabled where > possible. Right, but how does that relate to dyn_cast? I thought v-tables were present even when RTTI is not

Ehud, can you elaborate on which classes you're trying to change. I know some of the classes already use methods like getSubclassDataFromInstruction() to hide bits from the subclasses. They could probably shift the data too. ~Craig On Fri, Dec 27, 2019 at 9:35 AM Bruno Ricci via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 26/12/2019 20:53, Ehud Katz via

Hi, Do you have some code we can look at (even if it is in a nasty unpolished state, just mark it WIP and put it on Phab) ? It is hard to evaluate an alternative without the code. That said I think that the table is a little bit one-sided. I have added some inline comments. On 30/12/2019 11:53, Ehud Katz wrote: > The solution in Clang is still very complicated and error prone. A lot of

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!

How do you handle name lookup for nested classes? They have the same problem (they don't appear in all definitions) - don't appear in all descriptions of the outer/parent class. (in theory we could ensure there's always at least a declaration of the nested class - but we don't even do that if the nested class is unused) Is it just the case that Clang doesn't mind you adding a

> On Jun 15, 2018, at 1:48 PM, Pavel Labath <labath at google.com> wrote: > > On Fri, 15 Jun 2018 at 20:14, David Blaikie <dblaikie at gmail.com> wrote: >> >> How do you handle name lookup for nested classes? They have the same problem (they don't appear in all definitions) - don't appear in all descriptions of the outer/parent class. (in theory we could

This is just a quick note the let everyone know dyn_cast now works properly with BasicBlock::iterator's and others. In other words, you can now do things like this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(I); ++I) ... instead of this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(&*I); ++I) ...

It appears that LLVM has quite a number of dyn_casts (which I find quite natural) The suggested idiom: if (ConstantExpr* ce = dyn_cast<ConstantExpr>(*j)) { } is fine, and IIRC even used in TC++PL, but it occured to me that we can do even better: if (dyn_caster<ConstantExpr> ce = *j) { } where dyn_caster is defined like this: template<class T> class