similar to: [LLVMdev] TOT broken

Yes, this is pretty unacceptable IMHO. I would go revert crazy if I knew what to hit, unfortunately I don't. Currently I believe there are two problems, a CallGraphSCC assert which is firing everywhere (including the clang test suite, *cough*). This started with 80698. Chris is working on this (if it isn't already fixed). The bootstrap comparison failures are being looked at by Devang.

Hi All, I am facing miscompare error when running povray (and few other C/C++ benchmarks) from spec cpu2006 suite enabling FMA4 (and disabling FMA3). I have used -ffp-contract=fast to turn on this option. (Compilation options and targets pasted below). >>>>>>>> clang version 3.2 (trunk 163295:163308) (llvm/trunk 163295) Target: x86_64-unknown-linux-gnu Thread model: posix

On 03/30/2010 09:21 PM, Török Edwin wrote: > On 03/30/2010 09:15 PM, Tanya Lattner wrote: >> Thanks for testing the release! >> >>> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >>> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >>> and used the binaries for llvm-gcc. >>> >>> 1. llvm-gcc 2.7 vs

On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > I'm still slightly confused. Is the error now fixed or is there still a bug > in LLVM's integrated assembler? > The error is not fixed yet (even with fix mentioned in PR15040 http://llvm.org/bugs/show_bug.cgi?id=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but

Can you send the binaries compiled with and without the integrated assembler. Maybe I can figure out the encoding problem. I've been unsuccessful figuring it out myself so far. On Tue, Mar 12, 2013 at 12:34 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > > I'm still slightly

On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >> >> Are you still having issues with FMA4? I wonder if PR15040 is related. A >> fix was just committed. Unfortunately r173176 does not fix this. I have updated the trunk and ran...Miscompare still persists.

I would have thought this would have been possible. On Thu, Nov 17, 2011 at 3:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > So is this simply not possible? > > > On Thu, Nov 17, 2011 at 10:31 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> Nick, >> >> Thanks for this info, though this didn't help my problem at all. >> >>

The following code is causing an "UNREACHABLE executed!" and a stack dump, any ideas? namespace { struct myPass : public CallGraphSCCPass { static char ID; myPass() : CallGraphSCCPass(ID) {} virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); AU.addRequired<LoopInfo>(); } virtual bool runOnSCC(CallGraphSCC &SCC)

On Tue, Nov 29, 2011 at 6:59 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > The following code is causing an "UNREACHABLE executed!" and a stack dump, > any ideas? The stack might be handy. > namespace { >   struct myPass : public CallGraphSCCPass { >   static char ID; >   myPass() : CallGraphSCCPass(ID) {} >   virtual void getAnalysisUsage(AnalysisUsage

Hi all, I am experimenting to run a pass inherited from CallGraphSCCPass. In the pass, I iterate all functions in a SCC. In each iteration, I access all arguments of a function in the following way: Function::arg_iterator PI = fun->arg_begin(), PE = fun->arg_end(); ... I have no trouble with building. However, I am troubled with "segmentation fault" when I run the pass

The patch below basically hammers out some ideas as to where I'd like to take the passmanager in LLVM. I've tried thinking things through, but I'm still a n00b, so some criticism would be more than welcome. =) Starting from line 191 down. If you're wondering why I created a patch, well that's because I found thinking in passmanagert.h the most productive. -- Regards.

In addition to the link below, please check for functions like "llvm.debug.declare", "llvm.debug.value", as you will not get LoopInfo for these.   Pankaj   ________________________________ From: Devang Patel <dpatel at apple.com> To: Ryan Taylor <ryta1203 at gmail.com> Cc: llvmdev at cs.uiuc.edu Sent: Wednesday, November 30, 2011 11:08 PM Subject: Re: [LLVMdev]

I'm still slightly confused. Is the error now fixed or is there still a bug in LLVM's integrated assembler? On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 11 March 2013 17:00, Duncan Sands <baldrick at free.fr> wrote: > > Hi Anitha, > > > > > >> Ah, I am taking back my above words w.r.t encoding.

On Mon, 9 Jan 2006, Saem Ghani wrote: > The patch below basically hammers out some ideas as to where I'd like > to take the passmanager in LLVM. I've tried thinking things through, > but I'm still a n00b, so some criticism would be more than welcome. =) > > Starting from line 191 down. If you're wondering why I created a > patch, well that's because I found

UNREACHABLE executed! 0 opt 0x00000000008edc2f 1 opt 0x00000000008edfda 2 libpthread.so.0 0x00007f9c8e69bc60 3 libc.so.6 0x00007f9c8d986d05 gsignal + 53 4 libc.so.6 0x00007f9c8d98aab6 abort + 390 5 opt 0x00000000008da974 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 356 6 opt 0x000000000087e046 7 opt

Hi Chandler, I am now working on a bisecting tool to find mis-optimization on LLVM. I found OptBisect a very useful option and hope to make it work on the new pass manager. I have several questions about it. 1. Any plans to apply codegen stage with new pass manager? IIUC, new pass manager only works for opt stage. However the OptBisect option tries to accumulate pass counts through opt stage

Hi, I am using the scc_iterator class in my code on a CallGraph, where some functions are not called from within the module. It seems that scc_iterator does not list all SCCs if the graph is not connected; only those nodes connected to the node pointed to by GraphTraits<...>::getEntryNode() are returned. Can someone verify this behavior? Any tips on how I should go about extending the

On 03/30/2010 09:15 PM, Tanya Lattner wrote: > > Thanks for testing the release! > >> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >> and used the binaries for llvm-gcc. >> >> 1. llvm-gcc 2.7 vs 2.6 >> compared to my results from Aug 31 2009, ignoring CBE

Thanks for the info. Curious, do you know if there is an opt that will put all loops, including nested ones, in functions (ie each loop in it's own function)? What I'm trying to do is create a way for each loop to have only one exit. I want all loops to be single exit loops? I can write my own pass but I'd rather not. I think that if I can put each loop into it's own function

In the documentation, it says that a module pass can not require a function pass. Is it also true that a CallGraphSCC pass can not require a function pass? Ryan