search for: nondebugging

> > Are you able to run nightly test ? > Yes, I can run nightly test. > Here is what I see... > > $ make TEST=dbgopt > /Developer/usr/bin//llvm-gcc sse.expandfft.c -g --emit-llvm -c -o > Output/sse.expandfft.bc > /Volumes/Nanpura/mainline/llvm/Debug/bin/opt Output/sse.expandfft.bc - > strip-nondebug -strip-debug -std-compile-opts -strip -f -o Output/ >

Hi, I'm following http://llvm.org/docs/SourceLevelDebugging.html#debugopt to do the dbgopt testing. But seems, there is something wrong with the Makefile, it told me : llvm-gcc sse.expandfft.c -g --emit-llvm -c -o Output/sse.expandfft.bc llvm-gcc: sse.expandfft.c: No such file or directory llvm-gcc: no input files Am I missing something, like the configure option? -------------- next part

Bfu 91 to 92 looks good Proceed with xVM upgrade . After running:- # sunos.hg/bin/build-all nondebug bash-3.2# cd packages-nondebug bash-3.2# pwd /usr/tmp/packages-nondebug bash-3.2# ls -l total 20 drwxr-xr-x 4 root root 512 Jun 21 08:57 SUNWlibvirt drwxr-xr-x 4 root root 512 Jun 21 08:57 SUNWlibvirtr drwxr-xr-x 4 root root 512 Jun 21 08:57 SUNWurlgrabber

Hello LLVMers, I'm putting together some (extensive) experiments with using a genetic algorithm to construct sets of optimization passes that are as close as optimal in a number of ways, e.g. compilation time, execution time, code size, ... I've figured out which LLVM tools I should use for this (llvm-gcc to obtain bitcode, opt to optimize, llc to obtain assembly, ...), and I'm now

Dear Kenneth, May I ask you if you are implementing your search within ctuning framework: ctuning.org/ctuning-cc? The thing is that I use it since some time for my thesis to optimize code size and compilation time and run time with GCC though they are not using genetic algorithms but some slower hybrid of random exploration and than AI with some fronteer detection. Since recent version can be

On Jul 6, 2010, at 10:09 AM, Manuel Llosa wrote: > Dear Kenneth, May I ask you if you are implementing your search within > ctuning framework: ctuning.org/ctuning-cc? No, I'm not. I've built my own framework, and since I don't have any experience with the ctuning framework, I don't intend to start using that. There's little gain in it for me. > The thing is that I

Dear Kenneth, I see. Do you plan sharing your framework in open source? For now, I will continue using ctuning tools (they support LLVM as is but not some specific things on JIT dynamic recompilation what is my thesis about). I will like to compare all tools of course and will be happy to share results although real not until autumn).Look forward to your results and hopefully keep in touch.

udev knows about DEBUG=true and builds a debug binary. Maybe klibc should do the same? Was there a reason for -g in the i386 MCONFIG? Index: MCONFIG =================================================================== --- MCONFIG (revision 1003) +++ MCONFIG (working copy) @@ -62,5 +62,11 @@ # include $(KLIBSRC)/arch/$(ARCH)/MCONFIG +ifeq ($(DEBUG),true) +STRIP = /bin/true

On Jul 6, 2010, at 5:04 PM, Manuel Llosa wrote: > Dear Kenneth, I see. Do you plan sharing your framework in open source? > For now, I will continue using ctuning tools (they support LLVM as is but not > some specific things on JIT dynamic recompilation what is my thesis about). > I will like to compare all tools of course and will be happy > to share results although real not

It wouldn''t be proper to start my first post here without congratulations and thanks to the ZFS team for such an impressive piece of work. Anyway, on to my query. I''ve been trying out ZFS, with a particular focus in reducing latency in a specific application. This application has a fair amount of random writing going on in the background (which, of course, ZFS will make

[originally reported for ZFS on FreeBSD but Pawel Jakub Dawid says this problem also exists on Solaris hence this email.] Summary: on ZFS, overhead for reading a hole seems far worse than actual reading from a disk. Small buffers are used to make this overhead more visible. I ran the following script on both ZFS and UF2 filesystems. [Note that on FreeBSD cat uses a 4k buffer and md5 uses a 1k

Hello all, I am not sure my original mail got through to the list (I haven''t received it back), so I attach it below. Anyhow, now I have a saved kernel crash dump of the system panicking when it tries to - I believe - deferred-release the corrupted deduped blocks which are no longer referenced by the userdata/blockpointer tree. As I previously wrote in my thread on unfixeable