similar to: [LLVMdev] llvm.cs.uiuc.edu Services Restored

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] llvm.cs.uiuc.edu Services Restored"

2004 Jan 07
2
[LLVMdev] Services Restored
Dear LLVM Developers, The LLVM website, CVS repository, and SAFECode website should now be back online. Should you encounter any problems with the LLVM services, please send email to llvmdev at cs.uiuc.edu so that we may fix it. Regards, John T. Criswell ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu
2004 Jan 10
0
[LLVMdev] Services Restored
Hi, It looks like the CVS server is still not available. When I try to update with cvs, I get: cvs [update aborted]: connect to llvm-cvs.cs.uiuc.edu(128.174.245.58):2401 failed: Connection refused I know the server was down earlier this week but according to the message below, its supposted to be restored by now. Could someone please help? Thanks, Reid. On Wed, 2004-01-07 at 14:30, John T.
2004 Aug 10
0
[LLVMdev] CVS Services Restored
Dear All, I discovered a problem with our CVS server this morning. For some reason, the machine wasn't responding to network requests. I rebooted the machine and it appears to be working fine now, so if you couldn't use the LLVM website or CVS server before, you should be able to now. -- John T. -- ********************************************************************* * John T.
2004 Feb 23
0
[LLVMdev] LLVM Service Restored
Dear LLVM Developers, I am done (for tonight) working on the server, and all services should now be restored (LLVM web site, SAFECode web site, and LLVM CVS repository). If you find any of these services broken, please notify us by sending email to llvmdev at cs.uiuc.edu. Thanks, and sorry again for the interruption. Regards, John T. Criswell
2005 Jun 29
0
[LLVMdev] LLVM 1.5 C Front-End Binaries for FreeBSD?
Sean Peisert wrote: > John, > > I may be missing something here, but if I the compilation docs, I need > to build LLVM first and the C frontend second. But doing this, I > get: > > **llvm-gcc/llvm-g++ was not found, > > (obviously -- it wasn't installed, right?) You do need to build LLVM first before building llvm-gcc. This may seem a bit weird, but
2004 Jul 26
2
[LLVMdev] LLVM Server Back Up
Dear All, Our main server is back up, and all LLVM services (CVS, website, etc) should be up and available for use. If you notice that something is wrong, please send an email to llvmdev at cs.uiuc.edu. Thanks! -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer
2004 Sep 01
0
[LLVMdev] Mail Server Test Message
Dear All, This is simply a test message to see if the llvmdev list is operational. Please ignore. -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign
2005 Nov 01
4
[LLVMdev] LLVM Release Branch
Dear All, Do people think that they are ready to create the LLVM 1.6 release branch? I believe all the development is pretty much done. Is all the documentation in the LLVM source tree updated and ready? I'm not able to make a full doc review like I've been able to do in previous releases, so I need volunteers to work on the docs if they're not done yet. -- John T. -- John
2005 Nov 15
3
[LLVMdev] Moving CVS Files
Chris Morgan wrote: > Any reason not to upgrade to subversion? It does a much better job > with handling moved or renamed files although svn doesn't actually > store a 'move' or a 'rename' as a single versioned operation. We discussed moving to another revision control system about a year ago, if I recall correctly. At that time, we decided not to move to another
2005 May 17
2
[LLVMdev] Testing Release 1.5
Alexander Friedman wrote: > On May 17, John Criswell wrote: > >>Dear All, >> >>I've finished building binaries for the GCC frontends and am now testing >> the 1.5 release branch on i386/Linux, Sparc/Solaris, and PowerPC/MacOS X. >> >>I'm looking for volunteers to test LLVM 1.5 on platforms that we don't >>have in house. I'm
2005 Jun 28
2
[LLVMdev] Re: llvm linux/PPC cfrontend
Cyrille Mescam wrote: > Morning, > > I would like to know if you received my mail with the assembly code > you wanted. > > It not, i'll send it again to you. > > Thanks for your help. > > Regards. > > Cyrille > I've looked into the files you sent me, and it seems that the problem is occuring due to the C library simplication pass (which is run
2005 May 12
2
[LLVMdev] Current Regressions
Dear All, Here is a more complete list of regressions for the platforms listed below. Some of the regressions from the previous list I emailed a few days ago have been fixed or were false positives. Thanks to all who've helped fix things. We would like to try to get as many of these fixed as possible before I create the release branch (still scheduled for tomorrow, Friday). I'll
2005 May 27
0
[LLVMdev] A. Pool Allocation under PowerPC (Mac)
Ricardo wrote: > Hello, > > Is PA working on the macintosh already? Although we may not have run it on MacOS X recently, I believe that it should work. We've run it on several architectures and operating systems, including SparcV9/Solaris. If you find that PA doesn't compile or work on MacOS X, please file a bug report (http://llvm.cs.uiuc.edu/bugs/) so that we can fix it.
2004 Jan 05
0
[LLVMdev] System Downtime
Dear LLVM'ers, The LLVM web site (and possibly LLVM email) will be offline roughly at 8:00 am tomorrow morning (Tuesday, January 6). At that time, our machines will be moved to their new home at Siebel Center. We are hoping to have services restored by tomorrow night, but it may be as late as Wednesday before everything is back on-line. We apologize for the inconvenience. Regards, John
2004 Jul 27
1
[LLVMdev] ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (firstuse this function)
Hi John, Please see below, too >From: John Criswell <criswell at cs.uiuc.edu> >Date: Tue, 27 Jul 2004 14:57:02 -0500 > >Henrik Bach wrote: >>Hi, > >Please see below. > >> >>I get this error: >>------------------ >>ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >>ToolRunner.cpp:396: error: (Each
2005 May 28
1
[LLVMdev] SSA in the Front End
Thanks for the explanation. It's more clear now The only thing that seems strange is that in the function llvm_expand_shortcircuit_truth_expr in the front end, there is the creation of a PHI instruction. If there is no SSA yet, why do you do that? Thanks in advance --- John Criswell <criswell at cs.uiuc.edu> wrote: > Ricardo wrote: > > Hi, > > > > I have been
2004 Mar 24
0
Re: [LLVMdev] Compilation problem with 1.2 release
On Mon, 22 Mar 2004, Umar Janjua wrote: > Well, I compiled release but it gave error while making png library. > > The inclusion of zlib.h in the file png.h cannot locate file zlib.h. > If you change the inclusion to > > include "../zlib/zlib.h" instead of just "zlib.h" in png.h > > then compilation succeeds. I haven't seen a reply to this on LLVM
2005 May 27
0
[LLVMdev] SSA in the Front End
Ricardo wrote: > Hi, > > I have been looking into the code that generates the LLVM assembly in the LLVM front end, but I am > not very sure if at the time that the llvm_c_expand_body_1 function is called, the SSA form was > already constructed (each definition dominates all the uses). Can somebody please tell me? The LLVM GCC frontend does not translate variables directly into
2005 May 13
2
[LLVMdev] Current Regressions
Chris Lattner wrote: > On Thu, 12 May 2005, John Criswell wrote: > >> Here is a more complete list of regressions for the platforms listed >> below. Some of the regressions from the previous list I emailed a few >> days ago have been fixed or were false positives. Thanks to all >> who've helped fix things. >> >> We would like to try to get as many
2004 Sep 01
0
[LLVMdev] Type uint64_t required but not found
Who takes action on this? >From: John Criswell <criswell at cs.uiuc.edu> >Date: Wed, 01 Sep 2004 15:16:53 -0500 > >Henrik Bach wrote: >>Reid, >> >>>Well, if it doesn't break anything else, I'd fix the header file. The >>>standard type name is supposed to uint64_t not u_int64_t. I would just >>>change the header file to define both