similar to: [LLVMdev] Usage of /dev/null in makefiles wrong

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

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 ...

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

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

> 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 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

> 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

Hi Holger, On Thursday 19 July 2007 12:57:40 Holger Schurig wrote: > > 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

On Tue, Jun 17, 2008 at 4:56 PM, Edd Barrett <vext01 at gmail.com> wrote: > On Tue, Jun 17, 2008 at 4:51 PM, Edd Barrett <vext01 at gmail.com> wrote: >> I am trying the same with gcc-4.2 now. > > The above results were infact with gcc-4.2. My apologies. With 3.3.5 my first test took 5 times to produce a non "bus error" build. There were no 'make

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.

> Tomas, I'm Holger :-) > Please file a bug for this. Attach the .o files and command > line in question. Done, http://llvm.org/bugs/show_bug.cgi?id=1611

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 guess Bill Wendling cleared it up a little more for me. Neither llvm nor gcc ignore const. The type checking in each of their frontends makes sure that const is not violated. The reason I was asking about const is as follows. I was under the impression that const was part of c to aid the compiler with optimization and not just for type checking purposes. As you previously pointed out,

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

On Sat, 14 Jul 2007, Holger Schurig wrote: > 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

On Aug 16, 2007, at 9:09 AM, Chris Lattner wrote: > 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. If you use a const * __restrict pointer then you should get the benefit of this as the alias analysis will assume that the pointed to object is neither aliased nor

On Jul 18, 2007, at 8:06 AM, Holger Schurig wrote: > Seems like the memory-hog status is related to debug info, e.g. to -g. Perhaps this is related to the binutils bug discussed on the list recently (in certain versions of 2.17, I believe) that causes the native linker to behave very poorly when linking with debug symbols? http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-June/009391.html

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: {