search for: zion

...still rest in was that, that I restore after the fresh install. It seems that the disk were with problems and weren't syncing :(. I confessed, I didn't check that at first time but after I lost the data and check /var/log/messages I saw that. >From /var/log/messages ... Jan 17 12:22:15 zion kernel: md: raid1 personality registered for level 1 Jan 17 12:22:15 zion kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-09-14) initialised: dm-devel at redhat.com Jan 17 12:22:15 zion kernel: md: Autodetecting RAID arrays. Jan 17 12:22:15 zion kernel: md: invalid raid superblock magic on hda3 Ja...

...still rest in was that, that I restore after the fresh install. It seems that the disk were with problems and weren't syncing :(. I confessed, I didn't check that at first time but after I lost the data and check /var/log/messages I saw that. >From /var/log/messages ... Jan 17 12:22:15 zion kernel: md: raid1 personality registered for level 1 Jan 17 12:22:15 zion kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-09-14) initialised: dm-devel at redhat.com Jan 17 12:22:15 zion kernel: md: Autodetecting RAID arrays. Jan 17 12:22:15 zion kernel: md: invalid raid superblock magic on hda3 Ja...

.... It doesn't alter anything, all it does is build a set of "program instructions". For some reason even though if I run it with any other combination of passes I've found, anytime I run it with mem2reg I get a seg fault in dyn_cast! Here's output: Starting program: /mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc Program received signal SIGSEGV, Segmentation fault. 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const, llvm::Value const>::doit(llvm::Value con...

...ing, > all it does is build a set of "program instructions". For some reason even > though if I run it with any other combination of passes I've found, anytime > I run it with mem2reg I get a seg fault in dyn_cast! Here's output: > > Starting program: > /mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load > ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc This is a crash in your pass. Try running: opt -mem2reg test3.s.bc -o tmp.bc opt -load ... -metasplit tmp.bc -o out.bc I suspect that it will still crash in only y...

...package to work properly. I have used Red Hat 9, Suse 8 and Gentoo before migrating to LFS 5.0. In all earlier distributions it worked fine so I think the problem might be LFS specific though my mind refuses to believe this. Synopsis of the problem: LFS release 5.0 Samba Version 2.2.8a [root@zion ~]# smbclient -M zion added interface ip=172.26.112.41 bcast=172.26.255.255 nmask=255.255.0.0 Got a positive name query response from 172.31.1.11 ( 172.26.112.41 ) message start: ERRSRV - ERRaccess (The requester does not have the necessary access rights within the specified context for the...

...build a set of "program instructions". For some reason even > > though if I run it with any other combination of passes I've found, anytime > > I run it with mem2reg I get a seg fault in dyn_cast! Here's output: > > > > Starting program: > > /mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load > > ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc > > This is a crash in your pass. Try running: > > opt -mem2reg test3.s.bc -o tmp.bc > opt -load ... -metasplit tmp.bc -o out.bc I've already...

How big was that log file? If we are running close to the limit, I can just buy a new disk for zion. Other suggestions welcome. --Vikram On Nov 25, 2006, at 12:38 AM, John T. Criswell wrote: > Reid Spencer wrote: > > 1) It appears that the only problem was with sending email to the > llvm-commits list; any files commited to the repository should be > commited. > > 2)...

...some of the nightly testers to fail last night. The problem has already been fixed. Part of the problem was that it took 2 hours to get a commit through to CVS last night and the nightly tester had already started by that time. Something needs to be done about the late night high load situation on zion (backups?) Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050519/1a7c66ed/attachment...

I thought this conversation was worth saving. DannyB who did wonderful things with GCC's use of bugzilla has offered the same capability to LLVM. Thanks, Danny! <DannyB> sabre: BTW, if you need any of the bugzilla fun i have implemented for gcc, let me know [22:47] <sabre> Cool, what kinds of things do you have? [22:47] <DannyB> Besides the triplet stuff, i changed some of

...testers to fail last night. The problem has already > been fixed. Part of the problem was that it took 2 hours to get a commit > through to CVS last night and the nightly tester had already started by > that time. Something needs to be done about the late night high load > situation on zion (backups?) Hi Reid, The problem is that the disk on apoc (one of our machines) has been dying recently, and has finally totally died. It's not clear why the fate of zion (the machine with CVS and everything else on it) is tied to apoc, but it apparently definitely is. It is possible that...

All, Commits aren't taking right now because apparently Zion is out of disk space: cvs commit utils/findmisopt Checking in utils/findmisopt; /var/cvs/llvm/llvm/utils/findmisopt,v <-- findmisopt new revision: 1.9; previous revision: 1.8 done Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select q...

...) I took the LLVM web server down for a few minutes to copy the old log file on to a larger partition. The original is now deleted (i.e. we have room in /var/log again). All web services should be enabled now. -- John T. >All, > >Commits aren't taking right now because apparently Zion is out of disk >space: > >cvs commit utils/findmisopt >Checking in utils/findmisopt; >/var/cvs/llvm/llvm/utils/findmisopt,v <-- findmisopt >new revision: 1.9; previous revision: 1.8 >done >Insufficient disk space; try again later >Insufficient disk space; try again l...

Dear All, Our main machine, Zion, is back up with 2 GB of RAM. Our online webserver and CVS repository are now back up. Enjoy! -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer...

...can type in the username/password - then it takes about 5 minutes (you can still see the username/password dialog grayed) and then it tells me that it couldn't load my profile. I have the right permissions set at the profile directory. in the ldap.log file i get such messages: May 28 16:01:54 zion slapd[18348]: <= bdb_equality_candidates: index_param failed (18) May 28 16:01:57 zion last message repeated 7 times May 28 16:04:11 zion slapd[18348]: <= bdb_equality_candidates: index_param failed (18) why ? is it a failure with the indexes in sldap.conf ? i have: index objectClass...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi *! Has anybody a fix/workaround for this beahaviour? My Service[munin-node] is subscribed to the timestamp of a directory containing config-snippets like this: {{{ file{"/etc/munin/plugins": checksum => mtime, } service{munin-node: subscribe => File["/etc/munin/plugins"], # ... }}} When adding new snippets to the

...e exception drops through as expected. pz On 2011-07-21, at 5:45 PM, Garrison Venn wrote: > Sorry Peter, just saw this. > > If you are still having the problem: > > Did you set: llvm::JITExceptionHandling = true; ? > > Garrison > > On Jul 12, 2011, at 19:25, Peter Zion wrote: > >> Hi All, >> >> I'm trying to catch an exception that is "passed through" an LLVM ExecutionEngine but I am unable to do so. Specifically, in C++ code, inside a try/catch block, I call a JITted function, which in turn calls back into my code. Everythi...

...ed up with LLVM (in > comparison to GCC) on ackerman test on my AthlonXP. > But here: > http://llvm.cs.uiuc.edu/testresults/X86/ > GCC is reported to be quicker on > Benchmarks/Shootout-C++/ackermann test. This test seems PARTICULARLY noisy for some reason. Take a look at this: [zion Shootout-C++]$ time Output/ackermann.native Ack(3,12): 32765 3.130u 0.010s 0:03.14 100.0% 0+0k 0+0io 196pf+0w [zion Shootout-C++]$ time Output/ackermann.native Ack(3,12): 32765 3.280u 0.000s 0:03.28 100.0% 0+0k 0+0io 196pf+0w [zion Shootout-C++]$ time Output/ackermann.native Ack(3,12): 32765...

...need to do to get this behaviour to work? I admit that I have only a fairly basic understanding of how exception handling is implemented in C++ but from what I've read it seems like the exception should unwind through what is, for all intents and purposes, a simple call stack... Thanks, Peter Zion

Hi all i took a look into LLVM benchmarks from nightly tester and ran Shootout tests on my own. Below go just few outlines. 1. results on my AMD AthlonXP and Xeon used by LLVM team are different sometime. In particular, both Shootout and Shootout-C++ show great speed up with LLVM (in comparison to GCC) on ackerman test on my AthlonXP. But here:

...last I checked) with exceptions on. By default exceptions are turned off for most llvm libs. I would think that if: 1) setting: llvm::JITExceptionHandling = true; 2) building your process with exceptions on. your program should work. Hope this helps Garrison On Jul 21, 2011, at 17:47, Peter Zion wrote: > Yes, I did -- it made no difference. Should it? > > Note that I have since discovered that this is not a problem on Windows -- the exception drops through as expected. > > pz > > On 2011-07-21, at 5:45 PM, Garrison Venn wrote: > >> Sorry Peter, just saw...