similar to: mount shares

hi, - big and ugly mail. If you don't like them, delete it now :-) - I have collected and classified some information of: http://home.earthlink.net/~rwhron/kernel/bigbox.html And I observed that ext3 performance is worse than previous kernels(2.4.19...). -ac and -aa are here only as reference. Complete information is in the upper URL. dbench: Performance is worse. dbench (Numbers are in

hi i'm about to upgrade systems. yesterday i got https://www.zytor.com/pub/syslinux/Testing/6.04/syslinux-6.04-pre3.tar.xz in order to upgrade 6.04-pre1 version. i first was upgrading a usb-disk which was booting smootly with a simple configuration. i changed the EFI installation in /EFI/BOOT: efi64/efi/syslinux.efi (UEFI bootloader for EFI X64 (x86_64) firmware) ?

I am somewhat surprised people are actually using TCO. I had to fixed a number of subtle bugs to get it working and even now I am not too happy with it. My focus was on finding non-ABI changing automatic tail call cases (aka gcc's sibcall). It's now done so I'll leave -tailcallopt alone for now. I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Evan On Feb 5,

Getting this warning compiling on an alpha, is it a problem? 2.4.15-pre4 gcc -D__KERNEL__ -I/usr/users/donjr/linux-2.4.15-pre4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -DEXPORT_SYMTAB -c journal.c journal.c: In function `journal_init_inode': journal.c:758: warning: long long

Cyrille Berger wrote: > Unfortunately it's not fixed in 2.3 :( That's indeed unfortunate. On x86-64 the Pure interpreter currently is a 7MB behemoth, and most of that is LLVM. ;-) On 32 bit I have all that stuff in a separate runtime library, resulting in a 27K interpreter executable. It goes without saying that this makes a world of a difference. I don't care if LLVM is a shared

mriou wrote: > Using the sin(x) and cos(x) functions work though, only the ones included in > the main file don't. So I'm a bit puzzled... Did you link your executable with -rdynamic? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW:

Chris Lattner wrote: > Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Here are two typos I noticed: s/improvmenets/improvements/ s/GFortan/GFortran/ -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

Mikhail Glushenkov wrote: > I removed the '-relocation-model' bit from the default invocation > string for llc. To pass arguments to llc, use the new "-Wllc" > option. I'd say that this is the proper solution, even though it breaks backward compatibility on x86_64. But given that llvmc is still considered experimental, better do it now than later. ;-) Thanks a lot

Albert and Anton, thanks for all the answers. I tried to load a DLL with DynamicLibrary::LoadLibraryPermanently and it works perfectly, so there is no need to use ExecutionEngine::addGlobalMapping. However Function objects still need to be constructed since they are required when creating a call, right? Victor 2009/6/15 Albert Graef <Dr.Graef at t-online.de> > Victor Zverovich wrote:

Chris Lattner wrote: > We do not guarantee API stability at all, so this is just the tip of the > iceberg. I understand that. But in this specific case it would be very easy to maintain, no? > It seems that it would be relatively easy to get autoconf to make a > include/llvm/Config/Version.h file that did this. I already have the necessary autoconf magic to deal with this in my

John Criswell wrote: > The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X. The > following patch seems to fix it (it adds a missing include file to get > WeakVH defined). > > Has anyone else seen this breakage, or is it possible that I've got the > wrong branch checked out? I fails to compile on Linux as well. Has been that way for a few days. Albert --

Evan Cheng wrote: > As far as I can tell only PPC and X86 targets are supporting this option. Does anyone actually using it? I'd prefer to just remove it to clean up the implementation if no one has any objections. Don't know whether that is the same, but my Pure compiler sets llvm::PerformTailCallOpt. Pure needs TCO because it doesn't have any built-in looping constructs. In

Evan Cheng wrote: > I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Jeffrey apparently fixed that now, I'm going to test against trunk asap. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

My tests show x86_64 -tailcallopt JIT working fine on Mac OS X. Evan On Feb 6, 2010, at 6:43 AM, Albert Graef wrote: > Evan Cheng wrote: >> I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. > > Jeffrey apparently fixed that now, I'm going to test against trunk asap. > > Albert > > -- > Dr. Albert Gr"af > Dept. of

Jon Harrop wrote: > I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows > so I think TCO isn't working. Have there been any obvious changes that would > cause this? FWIW, Pure uses TCO as well and that works fine with LLVM 2.8, both with the JIT and with statically compiled code, at least on x86_64. -- Dr. Albert Gr"af Dept. of Music-Informatics,

On 07/05/2011 08:42 PM, Talin wrote: > 2) However, I don't think we should do this unless we can identify at > least one other customer other than myself - mainly because I don't want > the design decisions to be too tailored to my specific use cases. Pure would be another candidate, so I'd be interested in such a toolbox as well, especially in the synchronization primitives

On 10/17/2011 02:00 PM, Duncan Sands wrote: > this was a result of someone replacing 2.9 with 3.0 everywhere in that doc. > If you check the 2.9 release notes you will see that this was announced in > 2.9 release. Ah, I should have thought of that. :) > The 3.0 version does not require a patched gcc-4.5. It also works with > gcc-4.6. It does have its rough spots, but they were

Trying to get the Pure compiler to work with LLVM 3.1, I've run into a problem. The release notes say: "Target specific options have been moved from global variables to members on the new TargetOptions class, which is local to each TargetMachine." Unfortunately, they don't say anything about how to fix existing source to work around this. In my application I create a JIT

Hi Anton, On 05/08/2012 05:05 PM, Anton Korobeynikov wrote: > I believe examples/ExceptionDemo contains sample code which sets > TargetOptions flags. > In particular, llvm::EngineBuilder class has setTargetOptions() method > which does all necessary magic here. Cool, that's certainly easy enough. :) Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University

On 05/12/2012 04:22 AM, Keno Fischer wrote: > in order to get ready for the upcoming LLVM 3.1 release, I checked out > the 3.1 Release branch. However, unlike with LLVM 3.0, `llvm-config > --libfiles` now also reports files that belong to targets that I did not > build (and that are thus not available). Is this expected? I can confirm this. I always build LLVM with configure