search for: infloops

> You dropped some context... > A daemon program wouldn't be readonly. An infinite loop can be. Right. To prevent miscommunication, here is a quick analysis of a problematic (IMO) example: We start with ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret

On Sat, Jun 27, 2015 at 2:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > In C, dunno, but in LLVM, it means they aren't readonly :) In that case, -functionattrs needs to be fixed: define void @infloop() { entry: br label %l l: br label %l } == opt -functionattrs ==> ; Function Attrs: readnone define void @infloop() #0 { entry: br label %l l:

Hello testers, RC4 has just been tagged (at r229782 on the branch). RC3 was disqualified due to an infloop that Duncan reported, and fixed in r229421. That, fixes for a few scary X86 bugs, a GCC5 bootstrap problem (PR22625), and parts of PR22589 is included in RC4. Baring any showstoppers, this release candidate will be promoted to release. Please let me know how it looks and upload binaries

Btw, here is another interesting paper about post-dominators and control dependence: https://pdfs.semanticscholar.org/cbb2/9a0e4895025bd9df24f9263217df12f1ed1e.pdf I think a great outcome of your internship would be some precise documentation regarding the guarantees the LLVM dominators give -- possibly also considering classic and weak control dependence and the difference between

Hello all, Source and binaries for LLVM 3.6.0-rc4 are available at http://llvm.org/pre-releases/3.6.0/ There were only a few new patches since rc3: an infloop fix (r229421) a few X86 fixes (r229555, r229561 and r229564), a GCC 5 bootstrap fix (PR22625) and performance regression fix for PR22589. If this one looks good, it will be promoted to 'final' sometime next week. Thanks again to

----- Original Message ----- > From: "Nuno Lopes" <nunoplopes at sapo.pt> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, June 28, 2015 6:08:52 AM > Subject: Re:

Hi, I have a FunctionPass that requires a ModulePass using addRequiredById(). When I start opt it infloops somewhere in PMDataManager::findAnalysisPass. Should I open a bug, or is this a known issue (i.e. I am doing something wrong)? Is there a workaround? My modulepass just assigns unique numbers to basicblocks (like StableBasicBlockNumbering, but unique per Module) I could do that with a functionpa...

Final has been tagged, I think we're about to release it. On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> wrote: > Are we waiting for an RC5? It seems like the release mirror on github has > no recent activity. > > On Wed, Feb 25, 2015 at 3:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com > > wrote: > >> Quick update

Here's an initial stab, but I'm not too happy about the temporarily adding new instructions then removing it because returning it will have it added back in to replace other uses. I also added a couple test cases pass with the new InstructionCombining changes (the old code only passes one of the added tests). Also, this change exposes some simplification for

Quick update before I move on to the final tag. > clang+llvm-3.6.0-rc4-mipsel-linux-gnu.tar.xz > Still running due to a silly setup mistake on the first run (a broken > symlink to the test-suite source). Second attempt is a fair way through and > looks good so far though Default options were all good. Mips32 was about halfway but was good so far. >

instcombine can handle certain orders of "icmp"s that are "or"ed together: x != 5 OR x > 10 OR x == 8 becomes.. x != 5 OR x == 8 becomes.. x != 5 However, a different ordering prevents the simplification: x == 8 OR x > 10 OR x != 5 becomes.. %or.eq8.gt10 OR x != 5 and that can't be simplified because we now have an "or" OR "icmp". What would I

We got everything, haven't we? On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > Final has been tagged, I think we're about to release it. > > On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> > wrote: >> >> Are we waiting for an RC5? It seems like the release mirror on github has >> no

Are we waiting for an RC5? It seems like the release mirror on github has no recent activity. On Wed, Feb 25, 2015 at 3:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Quick update before I move on to the final tag. > > > clang+llvm-3.6.0-rc4-mipsel-linux-gnu.tar.xz > > Still running due to a silly setup mistake on the first run (a > broken >

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but

On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > At least in C/C++ that's UB, yes. So you cannot map every turing machine to a valid C/C++ program then. :) Also, does this mean that "daemon" programs that run continuously till they're killed by the OS (using a mechanism that is not visible in C) are effectively undefined? -- Sanjoy >

If you're able to reproduce the infinite loop with -O3 then you should be able to dump out the IR that causes `opt -instcombine` to infloop, unless the bug is truly esoteric (e.g. only caused by a specific use-list ordering). Maybe take a closer look at the output from `opt -print-before-all -O3`? Alternatively you can use bugpoint to minimize the IR to get a small reproducer that causes

This is probably only theoretical, but just the same... >From 29edcca195d2998ca4a54aacec261752a3bdeb3d Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Tue, 3 Nov 2009 18:50:23 +0100 Subject: [PATCH libguestfs] hivex: fail upon integer overflow * hivex/hivex.c (windows_utf16_to_utf8): Avoid overflow and a potential infloop. --- hivex/hivex.c | 3 +++ 1

We had several poor option-parsing actions in our ./nbdkit wrapper: Attempting './nbdkit --filter' went into an infloop with growing memory, because bash treats 'shift 2' when $# as a soft error (which we ignored) without even shifting 1, such that $# never decreases but $args[] continues to grow (dash, on the other hand, follows the POSIX recommendation of a hard error with

On Thu, Feb 9, 2017 at 8:41 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> What isn’t clear to me still is : why shouldn't this be transitive? >> In the example you’re showing, for a caller of f() in bar, what is the >> advantage of knowing that f()

I still haven't finished but I don't think you have to wait. On Fri, Feb 27, 2015 at 7:46 AM, Renato Golin <renato.golin at linaro.org> wrote: > We got everything, haven't we? > > On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > > Final has been tagged, I think we're about to release it. > > > > On Fri, Feb 27,