search for: 20130731

...one to the other: move one line of code. I hope my explanation makes sense, and it doesn't look like I'm dismissing your comment on implementation issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/fdd46a7c/attachment.html>

It would be really nice if our bug tracker had something like the "Issues: 30-day summary" that this jira instance has < https://issues.apache.org/jira/browse/LUCENE>. Another interesting statistic that might be interesting to plot alongside the "open bugs" graph is "total lines of code" (or maybe just plot the ratio "bugs/LOC"). -- Sean Silva On

...st > architecture-specific optimizations > You will need to do this in the frontend. The target independent optimizers are allowed to use the memory model. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/10d06659/attachment.html>

...ddle end. By only fixing it afterward, I don't see what the advantage of fixing it at all is... As Jeffrey pointed out, the penalty is relatively low on x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/0b168e1e/attachment.html>

> FWIW, I don't think we should add that, because it's an attempt to > define behavior that's undefined for other reasons (the data race on > the volatile). I had a discussion with Chandler and others, and something I misunderstood was pointed out: it is not an explicit goal of LLVM to support or continue supporting legacy code that did what it had to to express functional

Over most of the past year, I have been keeping an eye on the overall LLVM.org open-bug count. Sampling the count (almost) every Monday morning, it is a consistently non-decreasing number. I thought I'd post something about it to the Dev lists, as the count broke 4000 this past week. For your entertainment here's a chart that Excel produced from the data. (To make it more dramatic, I

Chris Lattner <clattner at apple.com> writes: > This thread is odd to me. It seems that the gist of your guys' > argument is that you don't know if we will ever get full support, > therefore we don't welcome progress towards that (very useful) > goal/feature. > > If the specific proposal doesn't make make sense from a design > standpoint, that's one

...v 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC 2012 i686 i686 i386 GNU/Linux Any ideas as to how to resolve this compilation error? Thanks Pranav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/c1d32f52/attachment.html>

...recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/8fabb37c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: speculatable.diff Type: application/octet-stream Size: 23140 bytes Desc: speculatable.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/8fabb37c/attachment.obj&...

..._____________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ec55cdc5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=60704 Priority: medium Bug ID: 60704 Assignee: nouveau at lists.freedesktop.org Summary: [nouveau, git regression] - I2C PWM fan control broken on nv50 adt7475 on kernels 3.3.x+ QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified

On 07/29/2013 09:15 AM, Sven Verdoolaege wrote: > On Mon, Jul 29, 2013 at 07:37:14AM -0700, Tobias Grosser wrote: >> On 07/29/2013 03:18 AM, Sven Verdoolaege wrote: >>> On Sun, Jul 28, 2013 at 04:42:25PM -0700, Tobias Grosser wrote: >>>> Sven: In terms of making the behaviour of isl easier to understand, >>>> it may make sense to fail/assert in case

...a follow-up on an earlier question. If MUL MVT::i32 is getting promoted (to MVT::i64), is there any way to distinguish the Node later as it goes through lowering? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/28d7eba0/attachment.html>

...perfect loops"? I was talking about perfect nests. I'm talking about perfect loop nests, as in the classical fortran loop transformation sense. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/672d7c62/attachment.html>

...is isn't about you, or this subject, or anything. It's simply not an appropriate place *for anyone* to ask about or formulate opinions about legal topics. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/d0cafaf2/attachment.html>

...is isn't about you, or this subject, or anything. It's simply not an appropriate place *for anyone* to ask about or formulate opinions about legal topics. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ba430570/attachment.html>

...o qcow2? i tryed with qemu-img convert -O qcow2 w.img w.qcow2 w.img are 75 gb fdisk w.img -l shows correct size but fdisk -l w.qcow2 shows totaly wrong! 0 mb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20130731/5e27fedc/attachment-0006.html>

...viour and can handle it. So >this is nothing I am very strong about. I just mentioned it as it seemed >to be a good idea. > >Cheers, >Tobias > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/274bbbb4/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ScopInfo-Create-shared-parameter-for-memory-accesses.patch Type: application/octet-stream Size: 6694 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

Cool. Thanks! -Jim On Jul 29, 2013, at 1:07 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 July 2013 20:39, Jim Grosbach <grosbach at apple.com> wrote: > These results are really excellent. They’re on Intel, I assume, right? What do the ARM numbers look like? Before enabling by default, we should make sure that the results are comparable there as well. > >

...UA: +380 572 931115 61070 Kharkiv www.ektos.com.ua <http://www.ektos.net/> E-mail: ppo at ektos.net Skype: potcheptsov.pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20130731/82e2b9ac/attachment-0001.html>