search for: rdar

I''m pleased to pass along news that the Mac OS X DTrace port has been updated in 10.5.3 to fix the issue that caused timer based probes not to fire in the presence of certain untraceable applications. http://blogs.sun.com/ahl/entry/apple_updates_dtrace A big thank you to the folks at Apple for addressing the problem. Adam -- Adam Leventhal, Fishworks

...5 .0.0 (trunk 2835 > 00f0 37342920 286c6c76 6d2f7472 756e6b20 74) (llvm/trunk > 0100 32383335 39392900 283599). > > It should be easy to enable for your platform if it's disabled/not there. It is disabled on MachO / Darwin though. Maxime: please ping this <rdar://problem/28847727 <rdar://problem/28847727>> — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161027/75aa8634/attachment.html>

...5393b1df1abf016b01f44d1d10a49/llvm/lib/Transforms/Scalar/TailRecursionElimination.cpp#L275 Looking through the tests that cover this scenario (https://github.com/llvm/llvm-project/blob/e29874eaa04d24b8c67776bf5729474d671a58f6/llvm/test/Transforms/TailCallElim/basic.ll#L66), I found it referring to rdar://14324281 and PR962. What are they? These haven't been updated since 2014, so I wonder what is the latest state and have them been resolved? cc nicholas who authored the original code. Thanks! -- Xun

On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: > Devang, > I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111114/b059f529/attachment.htm...

...get it now. TailRecursionElimination.cpp does two optimizations, marking of tail and converting recursion to loops. I thought you were proposing a change to the marking of tail. Thanks for the example! "PR962" refers to "problem report 962" or https://llvm.org/PR962 . "rdar" is Apple's "radar" bug tracking system, these are generally internal to their company but sometimes they're available in whole or in part on https://openradar.appspot.com/ . Nick > Specifically, I have been looking into an issue where Clang cannot TCE > the followi...

...sable stack slot sharing in functions that callsFunctionThatReturnsTwice(): // If there are calls to setjmp or sigsetjmp, don't perform stack slot // coloring. The stack could be modified before the longjmp is executed, // resulting in the wrong value being used afterwards. (See // <rdar://problem/8007500>.) if (MF.callsSetJmp()) return false; It might be possible for register coalescing to break something as well. /jakob

...44d1d10a49/llvm/lib/Transforms/Scalar/TailRecursionElimination.cpp#L275 > > Looking through the tests that cover this scenario > (https://github.com/llvm/llvm-project/blob/e29874eaa04d24b8c67776bf5729474d671a58f6/llvm/test/Transforms/TailCallElim/basic.ll#L66), > I found it referring to rdar://14324281 and PR962. What are they? > These haven't been updated since 2014, so I wonder what is the latest > state and have them been resolved? > > cc nicholas who authored the original code. > > Thanks! >

...g this, it should - it is a clear win. > > It is entirely possible I broke it when I added the COPY instruction. > > I deleted the RISC target hooks for foldMemoryOperandImpl, thinking that COPY folding was all they needed. The issue I'm looking at predates your COPY changes: <rdar://problem/7999181> values spilled to the stack should not need to be sign- or zero-extended

...n conditionalize the hack on the target triple being i386/x86-64. Just let me know. Some simple test programs look fine. It also turns out that my nightly tester picked up this change last night. I didn't see any obvious problems there except for a 13.5% regression on one internal test (<rdar://problem/8383253>) but that regression still reproduces with this change reverted. I sure don't want that hack to stick around for long, but as long as it gets removed soon, I guess we're fine for now.

Devang, I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. Chad On Nov 14, 2011, at 4:39 PM, Devang Patel wrote: > I filed PR 11378. > Thanks! > - > Devang > > On Nov 14, 2011, at 1:27 PM, Galina Kistanova wrote: > >> Hello Devang, >> >> Please find attached the preprocessed source file...

In that case I'll see if I can't bisect. Chad On Nov 14, 2011, at 5:32 PM, Devang Patel wrote: > > On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: > >> Devang, >> I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. > > It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. > - > Devang > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201111...

...that case I'll see if I can't bisect. > > Chad > > On Nov 14, 2011, at 5:32 PM, Devang Patel wrote: > >> >> On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: >> >>> Devang, >>> I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. >> >> It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. >> - >> Devang >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...

On Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > > On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > >> >> On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: >> >>> Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't*

On Thu, Oct 27, 2016 at 5:39 PM, Maxime Chevalier-Boisvert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > We’d like to keep track of which clang version was used to build our LLVM binaries. We use cmake and ninja with clang to build. What do you people think would be the cleanest way to know which version of clang is used, on a user’s machine, to build those binaries.

...e reliable by using a larger timeout value. This really isn't very good because it will still be susceptible to machine performance. While we are here also fix a bug in validation of `maxIndividualTestTime` where previously it wasn't checked if the type was an int. rdar://problem/40221572 llvm-svn: 332987 HTH, Dan. On Wed, 16 Sep 2020 at 09:37, David Blaikie <dblaikie at gmail.com> wrote: > > Ping on this > > On Wed, Sep 9, 2020 at 8:27 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > The clang-cmake-armv8-lld (lin...

Hello. I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public :)) Some discussion can be found here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102160.html. Unfortunately, no real testcase is provided, just abstrac...

...erstand why it fixes my bug. I'd love to know more. Especially, I'd like to produce a C/C++ snippet which repros the problem on a small scale. Your revision description indicates "Avoid replacing the value of a directly stored load with the stored value if the load is indexed. rdar://9117613." I've tried a variety of weird pointer manipulations like those found in tinyXML e.g. *p = *(p + 1), *(p+1) = *p. But none of my attempts seem to get it to fail the way my input bytecode failed. I'm trying to understand what 2011-03-10-DAGCombineCrash.ll is testing,...

I filed PR 11378. Thanks! - Devang On Nov 14, 2011, at 1:27 PM, Galina Kistanova wrote: > Hello Devang, > > Please find attached the preprocessed source file and the LLVM > bitecode. Hope this will help. > > Thanks > > Galina > > > > On Mon, Nov 14, 2011 at 9:48 AM, Devang Patel <dpatel at apple.com> wrote: >> The buildbot >> @

...in functions that > callsFunctionThatReturnsTwice(): > > // If there are calls to setjmp or sigsetjmp, don't perform stack slot > // coloring. The stack could be modified before the longjmp is executed, > // resulting in the wrong value being used afterwards. (See > // <rdar://problem/8007500>.) > if (MF.callsSetJmp()) > return false; > > It might be possible for register coalescing to break something as well. > > /jakob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

I cannot seem to probe any of the Python interpreter''s C functions on OS X. $ sudo dtrace -n ''pid$target::PyEval_EvalFrameEx:entry'' -c python dtrace: invalid probe specifier pid$target::PyEval_EvalFrameEx:entry: probe description pid59706::PyEval_EvalFrameEx:entry does not match any probes These functions show up in ustack()s, but they do not appear to be available