similar to: Question about versioning of LVVM IR

Thanks! Unfortunately this doesn't seem to cause it, because when I fix it to match the other files (and pretty much how clang emits it:) !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression()) !1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName: "f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope: !2, file: !3, type: !622, isLocal:

Hello everyone, I'm relatively new to LLVM and I would like to implement a feature, so I want your advice on its feasibility and difficulty. I want the code generator to support such code : %1 = ; <4 x float> vector %2 = ; <4 x float> vector %3 = fcmp ogt <4 x float> %1, %2 %4 = bitcast <4 x i1> %3 to i4 %5 = zext i4 %4 to i32 and generate a movmskps instruction

Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Thanks! Unfortunately this

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

Ok, I've done a bit more investigation. I found the module which declares broken DIE (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there: !2 = !DIFile(filename: "island.windows.elements", ... ... !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ... !5 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global",

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html IMO, the files to

Op 21-3-2018 om 10:28 schreef Evgeny Leviant: > It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context ||

2009/1/2 Chris Lattner <clattner at apple.com> > On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote: > Do you have a specific example of a unit test that would need these? I > really think these should stay private. > Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the high-level

Hello, everybody. We are working on a tool for mutation testing. The work is still in progress and far away from being done. However, we have got some results already. And we would like to share them with you. But, let me give you a brief introduction first. ### Mutation Testing In a nutshell, Mutation Testing is a way to evaluate a quality of a test suite. The approach suggests introducing a

On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 2:33 PM,

These warnings started appearing recently when building LLVM: llvm[2]: Compiling LLParser.cpp for Release build /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp: In member function ‘bool llvm::LLParser::ParseBr(llvm::Instruction*&, llvm::LLParser::PerFunctionState&)’: /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp:3195: warning: ‘Op1’ may be used uninitialized in

On Tue, May 10, 2016 at 11:45 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 3:38 PM, Peter

On Tue, May 10, 2016 at 3:03 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On May 9, 2016, at 4:42 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter

On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Mon, May 9, 2016 at 2:33 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Fri, May 6, 2016 at 2:10 PM, David

I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)

Hi all, I'd like to add support for metadata attachments for global variables in the same way as we did for functions. Syntax would be pretty simple: @foo = global i32 0, !foo !0, !bar !1 (the extra commas are required to disambiguate from a named metadata on the next line) Benefits: 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for

Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,

Hi Stanislav, Sorry -- I am not much help here. I would like to get ObjC runtime support for the JIT, but have not had time to look in to it closely. When I last tested the idea (a couple of years ago now) we used selector registration and objc_readClassPair to get basic test cases working as you have, but ran into (possibly similar) failures on non-trivial test cases. I think the interpretation

On Mon, May 9, 2016 at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Fri, May 6, 2016 at 2:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Fri, May 6, 2016 at 2:09 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Fri, May 6, 2016 at 1:55 PM, Peter Collingbourne

Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list