search for: schurig

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

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

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

...and 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 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 \ > > .obj/conf.o .obj/configwriter.o \ > >...

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

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

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

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://li...

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

> 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

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

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 \ > .obj/conf.o .obj/configwriter.o \ > -L/usr/share/qt3/lib -L/usr/X11R6/l...

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 demonstrate the concerns in all models, as I know significant research in massive data tables has been undertaken for decades... First:...

/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

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