similar to: [LLVMdev] llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float

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 > @ http://lab.llvm.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float/builds/850 > is failing with following assertion failure. Is it possible for

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

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 and the LLVM >>

Devang, I see the cause for confusion. Your message from this morning was specifically referring to this assert: Assertion `ExtVNI == VNI && "Unexpected existing value number"' failed. That assertion was fixed in the r144547. The PR shows this assert: Assertion failed: (isMetadata() && "Wrong MachineOperand accessor"), function Bisect fails until the

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:

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

> It builds here (Linux x86_64), I use the following configure line: > ../llvm-gcc4.2/configure > --prefix=/home/edwin/llvm-svn/obj42/../install --program-prefix=llvm- > --enable-llvm=/home/edwin/llvm-svn/llvm/ --disable-multilib > --enable-checking=release --enable-languages=c,c++ I'm using (x86-64 linux, gcc 4.3) ../gcc-4.2.llvm/configure --prefix=/usr/local/gnat-llvm

Since yesterday I've been getting the error below when building llvm-gcc on Ubuntu Hardy on x86. For some reason, several instances of autoconf are getting confused and failing to detect a stdlib.h. John /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/

I've hit a bug in a refactored version of coalescing and I'm trying to understand what is going on. In particular, I'm curious about this line in SimpleRegisterCoalescing.cpp: 00710 LHSValsDefinedFromRHS[VNI] = RHS.getLiveRangeContaining(VNI->def-1)->valno; Why VNI->def-1? The bug I'm seeing is that RHS returns a NULL LiveRange because it doesn't contain

On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > Since yesterday I've been getting the error below when building llvm- > gcc > on Ubuntu Hardy on x86. For some reason, several instances of > autoconf > are getting confused and failing to detect a stdlib.h. > > John > > > /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc >

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?

Hi, I have encountered a test case where InlineSpiller generates bad code. A register is reloaded but never spilled, and I suspect a bug in InlineSpiller. A register is live over a loop that also have two inner loops. It is not used or defined over the inner loops. It is split into two sibling registers, where one covers just the inner loops interval, which is then spilled. In spill(),

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

Anyone else seeing this? LLVM/gcc-4.2.llvm-objects/./gcc/xgcc -BLLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/include -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I.

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

LLVM is assuming this: struct InstrSlots { enum { LOAD = 0, USE = 1, DEF = 2, STORE = 3, NUM = 4 }; So VNI->def is always modulo 2. For coalescing, it's checking if the RHS is live at the "use" cycle. So it's checking VNI->def-1. Evan On Sep 25, 2007, at 8:55 AM, David Greene wrote: > On Tuesday

Hi! I'm estimating the number of basic blocks of the a program using "opt -stats bitecode.bc" I would like to save the output of the -stats opt into a file .txt. How can I do this? -- *Rafael Parizi* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120612/cc314c37/attachment.html>

Yes, I've tried and it did not work On Tue, Jun 12, 2012 at 4:03 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > Have you tried "opt -stats bitecode.bc > test.txt"?**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Rafael Parizi > *Sent:* Tuesday, June 12, 2012 11:36 AM > *To:*

Hi list, As long as I know English the word "bit" is a "small pice", . Why in set of documentation ir is "bytecode", in other set or llvm source is "bitecode"? What is the right? Different people call the same thing such differently. -- best regards Ariel -------------- next part -------------- An HTML attachment was scrubbed... URL: