similar to: [LLVMdev] Fun Name

On Apr 14, 2007, at 12:13 AM, Patrick Meredith wrote: >> >> All seriousness aside, I liked Illiacc (+1 for that one from me.) I'd > > I'm going to vote for illiacc too. It's just too good. Much as I like Illiacc too, I don't think we can use it. ILLIAC is the name of a series of well-known supercomputers built at UIUC, and (after a gap of some years), we

On Apr 13, 2007, at 6:08 PM, Scott Michel wrote: >> On Apr 11, 2007, at 9:44 PM, Chris Lattner wrote: >> >>> I think we need to >>> continue to use the name 'LLVM' to refer to the IR (i.e. that >>> which is >>> described in http://llvm.org/docs/LangRef.html), > > On the wackier side of "things that don't mean what they

> On Apr 11, 2007, at 9:44 PM, Chris Lattner wrote: > >> I think we need to >> continue to use the name 'LLVM' to refer to the IR (i.e. that >> which is >> described in http://llvm.org/docs/LangRef.html), On the wackier side of "things that don't mean what they seem": CosaNostra ("our thing"). All seriousness aside, I liked

Anyone tried using g++ 4.2.1 to build llvm yet? 4.2 has at least one serious bug that's a showstopper. -Dave

On 7/24/07, David A. Greene <greened at obbligato.org> wrote: > Anyone tried using g++ 4.2.1 to build llvm yet? 4.2 has at least one serious > bug that's a showstopper. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu

A simulator should be expecting the machine opcodes not macros. LD shouldn't care at all as long as the object format plays well. I would think it would be better to fix the simulator. Jack ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of llvmdev-request at cs.uiuc.edu [llvmdev-request at cs.uiuc.edu] Sent: Thursday,

On Wednesday 30 July 2008 16:03, David Greene wrote: > Ok, I've been tracking down a remat bug for over a week. I think I finally > understand what is going on. This happens in specfp2006 leslie3d > compiled with our frontend and optimizer. Unfortunately, getting a > testcase is going to be impossible due to restrictions on SPEC > redistribution and the complexity of the

Dear LLVM users, The development of LLVM has been supported primarily by funding from the National Science Foundation and the University of Illinois. in order to maintain our sources of funding and attract new ones, It is important for us to be able to document how LLVM is benefiting companies, universities, other organizations, and individuals in the outside world. (The information

I'm just beginning to explore Raqua on a new G5 machine. Generally, it feels very natural, but I'm puzzled by the behavior of editing windows. When you use fix() or vi() or edit() you get a new window; this is fine, but is there a way to: o specify what editor is operating in this window o control the size of the window o allow control to revert back to the R console with the

About 2 percent of the time I use fix() to edit a function that is sitting in .RData I get the response: > fix(qss) Error in edit(name, file, editor) : problem with running editor vi when I try to close the editing session. I used to think that these were always cases where there was some syntactical error with the edited file, but this is not the case. I realize that one surefire way to

So far we've tracked down four bugs using _GLIBCXX_DEBUG, all of them quite subtle and some of them leading to serious problems like heap corruption. But we've also discovered that compile time can skyrocket in some cases as the library does its checks. The standard library complexity guarantees don't apply with _GLIBCXX_DEBUG. Therefore, we should figure out if we want to enable

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does

greened at obbligato.org (David A. Greene) writes: > greened at obbligato.org (David A. Greene) writes: > >> For now, I think if I tweak the way I do the build to always build >> without pointing to llvm-gcc first, build and test LLVM then build >> llvm-gcc and re-build LLVM, it should work. It will take much longer, >> though. :( > > I updated the bug

greened at obbligato.org (David A. Greene) writes: > I have some pending patches for 3.0 only. Of course I meant post-3.0 only. -Dave

Yes, I do. -Chris On Jul 22, 2011, at 10:45 PM, greened at obbligato.org (David A. Greene) wrote: > Chris Lattner <clattner at apple.com> writes: > >> I really do appreciate distributed VCS, but only as staging. >> Incremental development is crucial for the project and "take this git >> push with 100K of code" will never be acceptable. > > I'm

greened at obbligato.org (David A. Greene) writes: > Often I run a few different builds in parallel, with different obj/build > directories. Is it possible that the test infrastructure writes > something to the source directories or some common temp directory? That > could confuse things when doing parallel build/test and would explain > all these failures. When I don't run

greened at obbligato.org (David A. Greene) writes: > Any hints on how to make absolute paths stick? Ok, I finally got that to work. I'm running experiments now. -Dave

greened at obbligato.org (David A. Greene) writes: > greened at obbligato.org (David A. Greene) writes: > >> Any hints on how to make absolute paths stick? > > Ok, I finally got that to work. I'm running experiments now. After fixing a few Python bugs in my code, I now have everything passing. Prepending the path to the tools being tested fixed all the problems. I will

Better be quick! I am adding FMA4 and XOP now, and if you contribute code before I do, you can spare yourself some XOP merging. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Benjamin Kramer <benny.kra at googlemail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 1, 2011 12:19 PM > Subject: Re: [LLVMdev]

Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at