similar to: [LLVMdev] CBackend bug fix

Reminder... Round one has been committed as <http://llvm.org/viewvc/llvm-project?view=rev&revision=107432> I hope that it got digested by now, as I plan to commit the second round tomorrow. In fact I made two test commits already: r107480 and r107580, the former of which actually uncovered some more uses of the low-level interfaces in core LLVM that have slipped through. To be

I put in two slightly different fixes that I believe should cover the problem: http://llvm.org/viewvc/llvm-project?view=rev&revision=156837 http://llvm.org/viewvc/llvm-project?view=rev&revision=156838 Let me know if your experience disagrees. I'll try and get these into 3.1 if Bill lets me after the buildbots give a check mark. - Daniel On Tue, May 15, 2012 at 5:38 AM, Keno

Quoting Gabor Greif <ggreif at gmail.com>: Hi Gabor, I can not open the link, can you send again? > AAAH! > > I see you are still at 2.5. Then this patch (the fix) > is relevant for you: > > <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ > ilist.h?r1=66061&r2=68785&diff_format=h> > > Cheers, > > Gabor > > >

Hey Daniel, Thank you for your help. I appreciate this. Your last tweak looks reasonable. However, there are 2 things with that: 1. It has changed the behaviour of the FindExecutable method. Before this change, it searched the directory the executable has been started from, then directories from PATH. Now it checks the current working directory first (makeAbsolute does this for just a file

Thank you for answering my E-mail. According to http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/047989.html, I open the link: https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.gpu.patch?root=kernelgen&view=markup https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.patch?revision=591&root=kernelgen&view=markup The result is: SCM Repository An Exception Has Occurred

2008/12/31 Chris Lattner <clattner at apple.com> > On Dec 30, 2008, at 2:54 PM, Talin wrote: > > OK changes made and new patch attached. > > +++ utils/unittest/Makefile (revision 0) > > ... > +# This has to come after Makefile.common, since it doesn't allow us to > +# override the VPATH value unless we set PROJECT_NAME, which we don't want > +# to do.

G'Day, Following Daniels comments about semantics of the sys::Path API, he has convinced me otherwise as the driver doesn't make or remove directories, so his semantics do indeed make more sense in this context. Fixes applied here; LLVM: http://llvm.org/viewvc/llvm-project?view=rev&revision=89848 Clang: http://llvm.org/viewvc/llvm-project?view=rev&revision=89849 Thanks everyone

As promised here comes the algorithmic part of the project. I have documented the way how the User object can be recovered from an array of Use objects. I have included a reference implementation in Haskell, along with a randomized test suite, which passes. This is just for those who want to manually prove the correctness of the C++ algorithm. If you wish I can remove (or move to another

> I can work around this by removing the two references to __eprintf > from lib/System/Win32/DynamicLibrary.inc, but... why are they there in > the first place, and why don't I have __eprintf on my system? > > I see that these references were introduced here: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=52037 > > but I don't understand what they

Hooray! I'm thinking that getting unit tests for the classes in ADT should be an early goal. I also wanted to mention a point about the general philosophy of unit testing, which is that the presence of such tests alters the calculation of risk when making changes to a code base. Programmers have various rules of thumb for estimating risk - for example, a change which affects a large

Hi Paul, You added some support for Haiku to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=83823 http://llvm.org/viewvc/llvm-project?view=rev&revision=106620 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it

Aaron Gray wrote: > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:

On Fri, Feb 27, 2009 at 7:14 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > >

On Sep 14, 2009, at 7:51 AM, Zoltan Varga wrote: > Hi, > > Would it be possible to merge this commit: > http://llvm.org/viewvc/llvm-project?view=rev&revision=80960 > > to the llvm 2.6 branch ? Without it, incomplete unwind info is > generated for functions with 0 stack size. Does it apply cleanly to the 2.6 branch? -Chris -------------- next part

On 4/22/14, Chris Lattner <clattner at apple.com> wrote: > > On Apr 22, 2014, at 7:28 AM, Gabor Greif <ggreif at gmail.com> wrote: > >> Hi devs, >> >> after my intentionally "playful" EuroLLVM presentation (*) I think it >> would be time to get serious about merging to ToT. But we should >> probably find out whether an optimized

Hi, Would it be possible to merge this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=80960 to the llvm 2.6 branch ? Without it, incomplete unwind info is generated for functions with 0 stack size. thanks Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 8 January 2013 17:01, Dmitri Gribenko <gribozavr at gmail.com> wrote: > r171853 for this one. Build not finished yet. > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4312 Thanks!! > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > > Looks like a better regex can fix this. > I think both of them are just bad FileChecks... This is

Hi devs, after my intentionally "playful" EuroLLVM presentation (*) I think it would be time to get serious about merging to ToT. But we should probably find out whether an optimized algorithm is desired at all. So I'd solicit comments from the code owners (Use.{h,cpp}) and anybody who is interested. For closer scrutiny, the code is here:

Chris wrote: > On Mar 26, 2008, at 3:16 PM, Gabor Greif wrote: > > here comes the patch for the first wave of Use class size reduction. > > > > I have split it into 3 files, corresponding to > > - header changes > > - implementation changes > > - applications > > nice! > > > This at the moment does not contain the description how the >

Sounds great to me Gabor. I really like your new incremental approach to this patch set. -Chris On Jun 30, 2010, at 1:59 PM, Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks >