search for: mdtupl

...ed a bug or if I'm misunderstanding something, I thought I'd >> ask here. >> >> Any ideas? > > This is a bug, and I believe it is caused by r266579. > > It seems that: > > 1) The module for a.ll is created. > 2) "!3 = !{void ()* @a}" is a MDTuple, and MDTuple nodes are leaking to the context and survive module deletion. > 3) "void ()* @a” which is the only element in this MDTuple is a “ConstantAsMetadata”, this does not leak and will be deleted with the module. > 4) a.ll is linked into an empty module, using an IRMover. This pro...

With 3.9, llvm-link tells me 'invalid subroutine type ref' when linking the two code pieces below, and I don't quite understand why. It looks like it merges the debug information with the custom metadata. I've filed a ticket already [1] but as I'm not sure if this is indeed a bug or if I'm misunderstanding something, I thought I'd ask here. Any ideas? Thanks, Robin

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with debugging symbols enabled, and this code has worked. However, on the Release+Asserts version, the third line results in a segmentation fault. The backtrace for the error, up to the method I'm working on...

..., and part of my additions >> include the following 3 lines of code: >> >> // newTypeName is a std::string >> MDString* newMD = MDString::get(M.getContext(), newTypeName); >> ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; >> auto* node = MDTuple::get(M.getContext(), mdArray); >> > > If I had to hazard a guess, it's that mdArray is left with dangling > pointers to an array (initializer list) that ceases to exist once the ';' > on line 2 is reached. So when the elements the ArrayRef references are > accessed...

...I've attached two WIP patches (which would be squashed before commit) and the WIP upgrade script I'm using. - transition-code.patch: Change the `DIDescriptor` hierarchy to lightweight wrappers around the subclasses of `DebugNode` (instead of rather heavier wrappers around `MDTuple`), and update `DIBuilder` to generate the right things. - transition-testcases.patch: Upgrade of testcases, entirely generated from the upgrade script (so far). - upgrade-specialized-nodes.sh: Script to upgrade LLVM assembly. (Feel free to have a look, but I haven't update...

...er/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x42b69) > #1 0x10c4a9f35 in llvm::MDNode::operator new(unsigned long, unsigned > int) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101588f35) > #2 0x10c4abc1a in llvm::MDTuple::getImpl(llvm::LLVMContext&, > llvm::ArrayRef<llvm::Metadata*>, bool) > (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10158ac1a) > #3 0x10c3af5ed in llvm::DebugLoc::get(unsigned int, unsigned int, > llvm::MDNode*, llvm::MDNode*) > (/Users/dexonsmith/data/llvm.a...

At least for generating DWARF the scope of of a composite type member should be irrelevant since it will always be nested inside its parent. -- adrian > On Feb 6, 2019, at 10:24 AM, David Blaikie <dblaikie at gmail.com> wrote: > > A good rough rule of thumb here is "what would/does Clang do?" & it looks (to me, on a very cursory glance) like Clang mostly passes the

...P patches (which would be > squashed before commit) and the WIP upgrade script I'm using. > > - transition-code.patch: Change the `DIDescriptor` hierarchy to > lightweight wrappers around the subclasses of `DebugNode` (instead > of rather heavier wrappers around `MDTuple`), and update > `DIBuilder` to generate the right things. > - transition-testcases.patch: Upgrade of testcases, entirely > generated from the upgrade script (so far). > - upgrade-specialized-nodes.sh: Script to upgrade LLVM assembly. > > (Feel free to have a...

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340