search for: qualtype

...ensions'. All my S4 classes have a method 'initialize' and R CMD check has never complained. Thus, do you have any idea why I get suddenly this warning for method 'initialize'? Here is the code for 'QualTreeSet': setClass("QualTreeSet", representation(qualtype = "character", qualopt = "character" ), contains=c("ProcesSet"), prototype(qualtype = "rlm", qualopt = "raw" ) )#QualTreeSet setMethod("initialize", "QualTreeSet", function(...

Hello Clang folks, I was using -ftime-trace to see where the compiler spends time parsing clang's own headers, and it pointed me to Type.h. Many AST headers need QualType to be complete, but they do not need the full type class hierarchy. To improve compile time, I have attempted to create a new header, QualType.h, that defines only the QualType wrapper class. I have started to transition popular clang headers (Decl.h, Expr.h, ASTContext.h, etc) to just use QualType...

...in the same file. The important part here is how you implement the classifyReturnType and classifyArgumentType functions, they should basically look like this: class MSP430ABIInfo : public ABIInfo { public: MSP430ABIInfo (CodeGenTypes &CGT) : ABIInfo(CGT) {} ABIArgInfo classifyReturnType(QualType RetTy) const; ABIArgInfo classifyArgumentType(QualType RetTy) const; virtual void computeInfo(CGFunctionInfo &FI) const { FI.getReturnInfo() = classifyReturnType(FI.getReturnType()); for (CGFunctionInfo::arg_iterator it = FI.arg_begin(), ie = FI.arg_end(); it != ie; ++it)...

I'm in the process of writing a clang-tidy check that concerns the position of the "const" keyword. The check should either enforce "T const" or "const T", based on a flag. Naturally, this should extend to all sorts of variations and qualifiers, e.g., X<const T&, Y const*> const&. My approach is to first find the right AST matcher expression to flag

...s.cpp.o): In function `(anonymous namespace)::PCHContainerGenerator::DebugTypeVisitor::VisitTypeDecl(clang::TypeDecl*)': /home/rdp/dev/llvm/llvm/tools/clang/lib/CodeGen/ObjectFilePCHContainerOperations.cpp:90: undefined reference to `clang::CodeGen::CGDebugInfo::getOrCreateStandaloneType(clang::QualType, clang::SourceLocation)' ../../../../lib/libclangCodeGen.a(ObjectFilePCHContainerOperations.cpp.o): In function `(anonymous namespace)::PCHContainerGenerator::DebugTypeVisitor::VisitObjCInterfaceDecl(clang::ObjCInterfaceDecl*)': /home/rdp/dev/llvm/llvm/tools/clang/lib/CodeGen/ObjectFilePCHC...

...g error- error: out-of-line definition of 'f' does not match any declaration in 'Y<T>' X<Y<T>::dim> Y<T>::f() { return X<dim>(); } Upon debugging I found that while parsing declaration " template <class U> X<Y<T>::dim> f();" qualtype of expression Y<T>::dim is treated as "const unsigned int" . But during definition of Non type parameter Y<T>::dim is treated as a dependent type and hence RebuildTypeInCurrentInstantiation is called but Y<T>::dim is still not resolved to "const unsigned int" a...

On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > Here is a patch that does just that. This does not work. I'm getting llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function ‘llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DICompileUnit)’: /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: error: call of overloaded ‘CreateDerivedType(unsigned int&, llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int, int, int, int, llvm::DIType&)’ is ambiguous llvm/include/llvm/Anal...

I came across a PDB that caused llvm-pdbdump to crash. I tracked it down to a missing overload for a data type in the variable printer. When I tried to provide an implementation, I discovered that there were some bugs in the existing overloads and it was easy to come up with combinations of types that weren't being dumped right. I created some test cases and tried to fix these problems but

Just got clang from head and getting: ExprConstant.cpp: In function Obool TryEvaluateBuiltinNaN(clang::ASTContext&, clang::QualType, const clang::Expr*, bool, llvm::APFloat&)¹: ExprConstant.cpp:1578: error: no matching function for call to Ollvm::StringRef::getAsInteger(int, llvm::APInt&)¹ /home/neale/LLVM/llvm/include/llvm/ADT/StringRef.h:269: note: candidates are: bool llvm::StringRef::getAsInteger(unsigned int, long...

...t; } > > the compilation fails with the following error- > error: out-of-line definition of 'f' does not match any declaration in 'Y' X::dim> Y::f() { return X(); } > > Upon debugging I found that while parsing declaration " template X::dim> f();" > qualtype of expression Y::dim is treated as "const unsigned int" . > But during definition of Non type parameter Y::dim is treated as a dependent type and hence RebuildTypeInCurrentInstantiation > is called but Y::dim is still not resolved to "const unsigned int" after call to Rebu...

...t;clang inline-test.c -std=c99 -fgnu89-inline -emit-ast -o inline-test.ast* *>clang inline-test.ast -std=c99 -fgnu89-inline -S -o inline-test.s* clang-3.2: $HOME/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:342: void clang::CodeGen::CodeGenFunction::*StartFunction*(clang::GlobalDecl, clang::QualType, llvm::Function*, const clang::CodeGen::CGFunctionInfo&, const clang::CodeGen::FunctionArgList&, clang::SourceLocation): Assertion `*CurFn->isDeclaration() && "Function already has body?"*' failed. >From crash message it seems Codegen is already emitted for inli...

...This has affected a couple more people recently (including me): http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048203.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20120326/055577.html If this interface could be improved, I believe clang simply apply a function to its QualType and produce an LLVM type which does the right thing. Without that improvement clang will have to use a context-sensitive model to map the whole sequence of arguments. At least, that's the ARM situation. I'm not sure Ivan's can even be solved without an improved interface (well, he...

...8:34 PM, Talin <viridia at gmail.com> wrote: > > Here is a patch that does just that. > > This does not work. I'm getting > > llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function > ‘llvm::DIType > clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, > llvm::DICompileUnit)’: > /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: > error: call of overloaded ‘CreateDerivedType(unsigned int&, > llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int, > int, int, int, llvm::DIType&)’ is ambiguo...

...Type, uint64_t Offset, bool IsConstant = false); So my questions are: - Is there any reason IsConstant is never set ? - Would it be valid to set this information according to the const-qualifier of the data accessed, maybe by getting it from QualType::isConstQualified()somehow ? Thanks, Marianne -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180427/c2e836f5/attachment.html>

...through GDB. This seems to be an ABI problem in clang. The problem seems to be that when we have pass by value of struct (having indirect arguments) stack is not aligned properly. I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - ABIArgInfo X86_32ABIInfo::getIndirectResult(QualType Ty, bool ByVal) ..... if (StackAlign == 0) return ABIArgInfo::getIndirect(4, /*ByVal=*/true, /*Realign=*/true); // Do a realign of stack. ... This seems to have fixed the issue. Also in case we have a large structure - e.g. - typedef struct s {...

...oject that extends C. I’m adding a new type of pointer that is a fat pointer. It has some metadata about the pointed object besides the starting address of the object. Currently I implemented this pointer as an llvm:StructType. In llvm::Type generation function llvm::Type *CodeGenTypes::ConvertType(QualType T) in the case for clang::Type::Pointer, instead of creating an llvm::PointerType I create an llvm::StructType type for this new type of pointer. And I added some helper code in llvm::StructType and in multiple places I added code to trick the compiler to believe sometimes a struct is actually a po...

...iable by value if it’s > obviously only loaded from in the expressions, but if the optimizers > still aren’t generally aware of the intrinsic, that will just mean > that assumptions pessimize slightly more abstracted code. > > For example, if I had this: > > ``` > Clang::QualType type = …; > __builtin_assume(!type.hasLocalQualifiers()); > ``` > > At a high level, I want to be able to apply mem2reg to the value of > this `QualType`; but at a low level, this method call takes `type` > by reference, and so the predicate function will take it by reference &...

...e people recently (including me): > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048203.html > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- > Mon-20120326/055577.html > > If this interface could be improved, I believe clang simply apply a function > to its QualType and produce an LLVM type which does the right thing. I don't think this is possible, for example I doubt you can handle the x86-64 ABI in a context free way. Without > that improvement clang will have to use a context-sensitive model to map the > whole sequence of arguments. > >...

...ype *T, raw_ostream &OS) { IncludeStrongLifetimeRAII Strong(Policy); SaveAndRestore<bool> NonEmptyPH(HasEmptyPlaceHolder, false); - printBefore(T->getPointeeType(), OS); + + // Suppress the printing of implied calling conventions. + QualType Pointee = T->getPointeeType(); + if (const AdjustedType *AT = dyn_cast<AdjustedType>(Pointee)) + Pointee = AT->getOriginalType(); + + printBefore(Pointee, OS); // Handle things like 'int (Cls::*A)[4];' correctly. // FIXME: this should include vectors, but vectors use...

On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed.