similar to: llvm.localsescape/recover

I would guess that %threedoubles has a large alignment and that is making things go wrong. I thought we fixed this bug, though. I can't find it in the tracker, but it's in there. Someone used __try with local variables of type 'double' on 32-bit and things didn't work out. I'm pretty sure we fixed it though. On Tue, Apr 3, 2018 at 4:53 AM Carlo Kok via llvm-dev <

That's quite likely. I can reproduce this issue with llvm 6.0 though. I'll try with svn HEAD. On Tue, Apr 3, 2018, at 19:22, Reid Kleckner wrote: > I would guess that %threedoubles has a large alignment and that is making things go wrong. I thought we fixed this bug, though. I can't find it in the tracker, but it's in there. Someone used __try with local variables of type

On Wed, Apr 4, 2018, at 08:58, Carlo Kok via llvm-dev wrote: > That's quite likely. I can reproduce this issue with llvm 6.0 though. > I'll try with svn HEAD. > > On Tue, Apr 3, 2018, at 19:22, Reid Kleckner wrote: > > I would guess that %threedoubles has a large alignment and that is making things go wrong. I thought we fixed this bug, though. I can't find it in

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

Hi, When running my own lld generated library/executable I'm getting: LD_LIBRARY_PATH=. ./ConsoleApplication347 ./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347: undefined symbol: (theres nothing after undefined symbol) How can I figure out what's I'm doing wrong? Full log: https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656 readelf -s for

I think r262546 introduced the assumption that allocas are used exactly once with catchpad. It seems easy to fix, though. On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This turned out to be related to reusing the local used in the catchpad, > for example given the following c++ code: > > extern void rthrow(); > > int

Hi, I have a function with: attributes #2 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" } Yet when compiling it generates: https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3 (Note how it checks fFinalizer before setting up ebp). It also has a: .loc 36 195 7 prologue_end before this happens How can I get llvm to do the frame

Hi, I'm gettign an assertion fail/crash in X86FrameLowering::GetFrameIndexReference when compiling the following bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 I tried removing the llvm.frameaddres calls but that's not it, where can I start looking for what my mistake here is? Code seems to verify just fine. ; #0 0x00e1afe8

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

On a 12" MacBook (2017) with 2 cores I get lld/wasm to be stuck in: https://gist.githubusercontent.com/carlokok/1a14e7ed3dbbd54511e1f0b3a7d684ff/raw/19267560b584ca42cc66f44f508df5b34102d803/thread%2520for%2520waiting It seems the outer for loop exhausts the thread pool, and the inner ones trigger a new parallel for which never finishes because the pool is full. Is this a bug or am I

It's a wasm testcase that ends up with a 1 mb executable; after 15 minutes I killed it, it doesn't do anything (note that it's waiting on a conditional variable in ALL threads) On Wed, May 8, 2019, at 14:32, Brian Cain wrote: > Are you sure it's not just taking "a long time"? If that build machine doesn't have enormous amounts of memory you could end up with a

Hello! At Sony we've seen some serious customer interest in having the 'this' pointer visible throughout an entire function during debugging. However, optimizations may eliminate it after its last use, so we've been looking for a way to artificially extend its liverange to the end of the function. So far, the most compelling way we can think of, and one we have used successfully

(Currently using a build from november but I didn't see any commit that could fix this for wasm); With the wasm backend, %2 = icmp sgt i8 %0, -1 becomes: i32.const $4=, 255 i32.const $2=, 255 i32.and $3=, $0, $2 i32.const $5=, 255 i32.and $6=, $4, $5 i32.gt_s $7=, $3, $6 Which essentially does

On 2016-12-22 19:02, David Blaikie wrote: > 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. > That's my guess too, special behavior when it sees an alloca.

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: >

I think probably the simplest answer is that dbg.declare documents that it must point to an alloca ("This intrinsic provides information about a local element (e.g., variable). The first argument is metadata holding the alloca for the variable. ") - so it's probably best not to think too hard about what it does when that criteria is not met.

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const

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

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

Hello, Can you check whether your build includes r317710 <https://llvm.org/svn/llvm-project/llvm/trunk at 317710>? Thanks, Dan On Thu, Jan 11, 2018 at 12:51 AM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (Currently using a build from november but I didn't see any commit that > could fix this for wasm); With the wasm backend, > > > %2 = icmp