similar to: debug info "ref" parameter

Could you provide the complete example (with all the necessary metadata to reproduce)? Possible LLVM has a special case for arguments, I'm not sure/don't recall off hand, but can poke around at it & see if there's a reasonable logic to it. On Tue, Dec 20, 2016 at 10:43 PM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I want to emit a ref parameter (ie

https://gist.github.com/carlokok/77010598f81e8167592e593ec6c715a1 If needed I can strip it down more tomorrow, but only elements entry point and the two meh methods are used. On December 21, 2016 8:27:12 PM GMT+01:00, David Blaikie <dblaikie at gmail.com> wrote: >Could you provide the complete example (with all the necessary metadata >to >reproduce)? > >Possible LLVM has a

if you could simplify it down a bit, that might be helpful - not sure there's a lot to be gained - I imagine it is just a quirk of how we handle these things in the backend to make normal debug info work, but there might be some things to be done to help. On Wed, Dec 21, 2016 at 2:31 PM Carlo Kok <ck at remobjects.com> wrote: >

Hi, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

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

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via

using `opt --print-after-all -O3` I see that EarlyCSE is interpreting the call to `ceil` and constant fold: *** IR Dump After Early CSE *** ; Function Attrs: nobuiltin nounwind define i1 @do_test() #2 { Entry: %0 = call fastcc float @ceil(float 0.000000e+00) #6 %1 = call fastcc float @ceil32(float 0.000000e+00) #6 %2 = fcmp fast oeq float 0.000000e+00, %1 ret i1 %2 } So just running `opt

I just reported this bug: https://bugs.llvm.org/show_bug.cgi?id=35314 This very simple IR is causing infinite recursion in llvm::DwarfUnit::getOrCreateTypeDIE in llvm 5.0.0. Is there a workaround? Is anyone willing to save me a recompile and check if this is fixed in 5.0.1 or trunk? `clang -c test.ll` repros the issue. ; ModuleID = 'test' source_filename = "test" target

Is there a more convenient way to obtain a DIType given a Type than matching up the strings for the names? For example, given: struct S { int x, y; } s; void foo(S *a) { a->x = 0; a->y = 1; } There are DIType nodes for the struct Type: !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !3, line: 1, size: 64, flags: DIFlagTypePassByValue,

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

Hi, I see things like this. What does it mean? Is it documented somewhere? Thanks. ; preds = %for.body https://llvm.org/docs/LangRef.html ; <label>:91: ; preds = %88 %92 = load i8**, i8*** @glob_complete_word.matches, align 8, !dbg !99798 %93 = load i32, i32* @glob_complete_word.ind, align 4, !dbg !99799 %94 = sext i32 %93 to i64, !dbg !99798

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

Greetings, I have a Zig implementation of ceil which is emitted into LLVM IR like this: ; Function Attrs: nobuiltin nounwind define internal fastcc float @ceil(float) unnamed_addr #3 !dbg !644 { Entry: %x = alloca float, align 4 store float %0, float* %x call void @llvm.dbg.declare(metadata float* %x, metadata !649, metadata !494), !dbg !651 %1 = load float, float* %x, !dbg !652 %2 =

Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm not familiar with your frontend but you might want to use -mllvm -opt-bisect-limit. On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote: Valgrind is strictly better than address sanitizer, is that right? It runs valgrind-clean: [nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind

Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer