similar to: [LLVMdev] PATCH: clang: fix description for -Wimplicit-function-declaration

This implements -dry-run for llvmc2: $ llvmc2 -dry-run main.c llvm-g++ -c -x c main.c -o /tmp/llvm_bGw2gN/main.bc -emit-llvm llc -f /tmp/llvm_bGw2gN/main.bc -o /tmp/llvm_bGw2gN/main.s llvm-gcc -c -x assembler /tmp/llvm_bGw2gN/main.s -o /tmp/llvm_bGw2gN/main.o llvm-gcc /tmp/llvm_bGw2gN/main.o -o a.out $ llvmc2 -dry-run -opt main.c llvm-g++ -c -x c main.c -o /tmp/llvm_UGZtwL/main.bc -emit-llvm opt

Tomas, Please file a bug for this. Attach the .o files and command line in question. Thanks, Reid. On Wed, 2007-08-15 at 23:22 +0200, Tomas Lindquist Olsen wrote: > I think I have experienced this when more than one module contains > definitions for the same values. ie. it should only be a declaration > in one of them. > > On 8/15/07, Holger Schurig <hs4233 at

I'm using llvm-ld from SVN r41106 When issueing the command $ /usr/src/llvm/installed/bin/llvm-ld -v -stats -native -O1 -strip-all -o main \ .obj/conf.o .obj/configwriter.o \ -L/usr/share/qt3/lib -L/usr/X11R6/lib \ -lcrypto -lusb -lutil -lqt-mt -lXext -lX11 -lm -lpthread I get this output: Linking bitcode file '.obj/conf.o' Linked in file '.obj/conf.o' Linking

I realize I am one of the few who uses the segment registers (especially CS and DS) on the ia32 chips for example, and a definite few with complete segregation models that rival specialized physical processors... GCC still fails to use these correctly and if your LLVM still depends on either Generic or some of the RTL models they use in various processor definitions, I express concern for

I think I have experienced this when more than one module contains definitions for the same values. ie. it should only be a declaration in one of them. On 8/15/07, Holger Schurig <hs4233 at mail.mn-solutions.de> wrote: > I'm using llvm-ld from SVN r41106 > > When issueing the command > > $ /usr/src/llvm/installed/bin/llvm-ld -v -stats -native -O1 -strip-all -o main \ >

Hello All, Sorry to rehash a question I am sure has shown several time but I cannot google up the answer from the lists. Does anyone know where I can get some royalty free, cost free music for my music on hold? I saw someone's post several weeks ago that said that this exists at a download site but I have not been able to find it. Thanks! Wiley Siler -------------- next

fucking hell, listserv... ---------- Forwarded message ---------- From: "Wilfred L. Guerin" <wilfredguerin at gmail.com> Date: Wed, 25 Jul 2007 10:54:46 -0500 Subject: Re: [LLVMdev] Segment Register Use To: Holger Schurig <hs4233 at mail.mn-solutions.de> I was very much expecting this style of response ;) I believe the following characteristics and class of example should

/usr/src/llvm/llvm$ make make: Warning: File `/dev/null' has modification time 4.9e+03 s in the future make[1]: Entering directory `/usr/src/llvm/llvm/lib/System' ... At the end of the compilation it emits something about clock skew detected. The time of /dev/null on my box is weird because of udev and/or time local settings. When it's created, the init scripts didn't

On Thu, 16 Aug 2007, Holger Schurig wrote: >> if the programmer is going to tell you that the memory pointed >> to by a pointer argument is never written. > > There are ways to cast away a const. You don't even need casts: void foo(const int *P, int *Q) { x = *P; *Q = 1; y = *P // redundant? } void bar() { int X = 0; foo(&X, &X); } -Chris --

> LLVM represents debug info as explicit calls to intrinsics. > This approach has many advantages, but a possible disadvantage > is that it can significantly increase the size of the bitcode. > I don't know if that explains your observations. I'm curious > to know how gcc stores debug info... GCC stores debug info in ELF sections of the .o file, e.g.: $ objdump -h wtd.o

> If you use bison instead of yacc this bug is not exposed. > > Is this correct behavior? I guess so. bison is quite different to yacc, see "info bison". llvm depends on bison and this is quite well documented. At http://llvm.org/releases/2.3/docs/GettingStarted.html#software it says "bison" and specifically which version of Bison you've to use.

> The idea is to use llvm to put performance sensitive code into > a DLL that a Windows app can then use. > > This would build the performance sensitive code on the target > machine making it possible to exploit CPU specific x86 > vector instructions. Isn't this what Apple does with OpenGL, except that they skip the DLL step?

I yesterday brought up to date the version of * the CVS and now I have a problem. I cannot effect the RELOAD that * it breaks. Somebody can help or say as to load new users without stopping * ? Thank?s Excuse my English Joao Carlos Moura

> if the programmer is going to tell you that the memory pointed > to by a pointer argument is never written. There are ways to cast away a const.

I am seeing a very strange situation where doing: make -C dir all does not rebuild anything in dir, even though stuff is stale. This command is what the recursive makefile uses to walk the directory structure. The really strange thing is that: cd dir; make all does rebuild stuff. Does anyone have any idea what is going on here? I thought they were identical. -Chris

> make -d -C dir all >run1 > cd dir; make -d all >../run2 cd .. diff -udb run1 run2 | less But maybe you don't have GNU make, but some Apple (BSD-derived) make which doesn't have the "-d" switch ...

I can compile LLVM using with this method: svn co ... cd llvm ./configure ... make or with that one: svn co ... mkdir obj cd obj ../llvm/configure ... make How does the second method work with the new, experimental C compiler, "clang" ? The doc said that you put the clang sourcecode into llvm/tools/clang, change into this directory and simply enter "make". This seems

Hi Holger, On Mon, 2007-07-23 at 09:28 +0200, Holger Schurig wrote: > /usr/src/llvm/llvm$ make > make: Warning: File `/dev/null' has modification time 4.9e+03 s > in the future > make[1]: Entering directory `/usr/src/llvm/llvm/lib/System' > ... > > At the end of the compilation it emits something about clock skew > detected. > > The time of

Are JIT DLLs supported? The idea is to use llvm to put performance sensitive code into a DLL that a Windows app can then use. This would build the performance sensitive code on the target machine making it possible to exploit CPU specific x86 vector instructions. The code that calls fn's in the DLL should, ideally, be unaware that a llvm JIT is being used. -- Øyvind Harboe

> With 3.3.5 my first test took 5 times to produce a non "bus > error" build. There were no 'make cleans' in between. > > What is going on? You mean you used your bsd-ports-provided gcc to compile LLVM and you've got 4 times a bus-error during the build? In this case, it cannot be a LLVM problem. In the linux-community, people say that bus-error's are