search for: resurrected

Hi, I'm using a recent RELENG_6 under I386/SMP (Athlon X2 4800+). dmesg output is under http://people.freebsd.org/~mr/dmesg.log.gz Root is on gmirror volume (2 SATA disks), a backup FS is on graid3 (5 firewire disks). This server acts as an bacula server. During backup with bacula I discovered an complete system freeze (no keyboard, nfs, disk...) after the following lines on the screen: ...

I'm thinking I should make a commit robot (like the tip-bot for the Linux kernel) for klibc since development has been picking up again. I could revive the old klibc-cvs mailing list, or make a new one from scratch, or even direct all the commits to the main klibc mailing list. What would people's preference be, here? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work

Hi everybody I?d like to resurrect the discussion on a known issue with the openssh server, regarding signal delivery as described in rfc4254 This has been originally reported about ten years ago in this thread: https://bugzilla.mindrot.org/show_bug.cgi?id=1424 I am taking he liberty to copy a few people who contributed that thread over time The discussion does not seem to expose the reasons

I think the C backend also allow people performing source-to-source transform with LLVM (instead of Clang). ether On Tue, Aug 28, 2012 at 10:30 AM, Philipp Klaus Krause <pkk at spth.de> wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only

On 8/27/2012 9:57 PM, Hongbin Zheng wrote: > I think the C backend also allow people performing source-to-source > transform with LLVM (instead of Clang). I do not believe that this would be the case nor that it should be a goal. Source-to-source transformation requires a lot of accurate information about the AST, and conversion to LLVM IR is way too lossy. Signedness, for example, is

Hi Roel, It's good to know that you're working on C backend. But IMO, the reason that C backend was removed in LLVM 3.1 is no one maintain the C backend. If you bring it back, would you like to take the responsibility for the maintaining work? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

On 27.08.2012 22:56, Roel Jordans wrote: > > Anyway, that brings to my final question: Which features are > critical/important/wanted/unwanted for a C back-end? > I'd like it to be easy to configure (e.g. to tell which size int is assumed to have). I'd prefer the resulting code to not rely on implementation-defined behaviour (e.g. not make any assumptions about the size of

Hi Everyone! I've been trying to rediscover the lost art of appliance-ification. SystemD is actually pretty amenable to masking tty1 and spawning a program instead of login which makes a config console a rather easy thing to do (mostly). Have that bit done, no problem. Happily spawning a rather locked down program. However, you seem to be limited in terms of color palette, creating a new

flac123 is back! Version 0.0.3 is now available at http://flac-tools.sourceforge.net . flac123 now supports FLAC 1.1.0, and its remote mode mimics mpg123's. Please test it for bugs and report them to the flac-tools sourceforge forum. _________________________________________________________________ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now!

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

I have a small file of the type that S-PLUS produced and stored in .Data/ directories back in the days before we used R. I'm fairly sure it would become a dataframe if read into Ver 3.4 of that august predecessor to what we use now. (It was Solaris in case that makes any difference.) AFAIK, the format that S-PLUS uses changed after that, so a current version would find it unreadable. If

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > On 28.08.2012 14:08, Joshua Cranmer wrote: >> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>> I think the C backend also allow people performing source-to-source >>> transform with LLVM (instead of Clang). >> >> I do not believe that this would be the case nor that it should

On 28.08.2012 14:47, Cameron Zwarich wrote: > On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > >> On 28.08.2012 14:08, Joshua Cranmer wrote: >>> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>>> I think the C backend also allow people performing source-to-source >>>> transform with LLVM (instead of Clang). >>>

On 28/08/12 04:30, Philipp Klaus Krause wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only a C compiler exists? > Which use-cases do you have in mind for this backend? > Possibly yes, compiling C++ to C would require support for things

Will this allow users to compile C++ (or some other language that LLVM has a frontend for) to C, which then can be compiled using a C compiler for a target architecture, for which only a C compiler exists? Which use-cases do you have in mind for this backend? Philipp

On 28.08.2012 14:08, Joshua Cranmer wrote: > On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >> I think the C backend also allow people performing source-to-source >> transform with LLVM (instead of Clang). > > I do not believe that this would be the case nor that it should be a > goal. Source-to-source transformation requires a lot of accurate > information about the AST,

I had a CentOS 5.5 Xen "standard virtualization" install lockup on reboot after an battery backup (apcusbd) orderly shutdown induced by a power outage. It may have been sitting with two kernel updates without a reboot. I have to head to the site (with a fractured ankle), but reports indicate that it is at - (none) login: which only returns back to itself after a user login at

...in bug database on this topic. > Now after 3 years, what's the status of this issue? Are there still any > problems in the pass if i compile and run it? > > > I do not believe that the status has changed. I believe the -dsa-aa pass > in DSA is still removed and has not been resurrected (at least not with a > patch that applied cleanly to the release_32 branch). > > If someone wants to resurrect -dsa-aa with a patch that cleanly applies to > the release_32 branch or the trunk branch, I'll review it and apply it. > > Regards, > > John Criswell > >...

...p://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > There is even qemu support for microblaze. I think it's excessive to remove a port so easily. Once you announce that you want to remove it, you should wait at least a year. It may have to wait for funding to be resurrected. gcc had ports that nobody used for 10 years before they finally deleted them. Reed