search for: podlaski

On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: > In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. > It may require some changes to ‘Makefile.rules’ to work as > intended, though. If there's interest in such a change, I can prepare > a patch? Are OPTIONAL_DIRS parallel? For some reason,...

On 19 Jan 2009, at 21:16, Mike Stump wrote: > On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: >> In my humble opinion, using OPTIONAL_DIRS would be better and >> cleaner. >> It may require some changes to ‘Makefile.rules’ to work as >> intended, though. If there's interest in such a change, I can prepare >> a patch? > > Are OPTIO...

On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote: > On 19 Jan 2009, at 21:16, Mike Stump wrote: > >> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >> wrote: >>> In my humble opinion, using OPTIONAL_DIRS would be better and >>> cleaner. >>> It may require some chan...

This patch eases building clang when present in the source tree. Since clang is revlocked to llvm, one usually updates them together, and builds them together. Ok? -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-3.patch Type: application/octet-stream Size: 794 bytes Desc: not available URL:

...them together, > and builds them together. > > Ok? In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. It may require some changes to ‘Makefile.rules’ to work as intended, though. If there's interest in such a change, I can prepare a patch? -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com

...ope to have most of my changes to the build system integrated, and plan to post a proposal of how to get it done within the next few days or so. Apart from a general overhaul of the Makefiles, I integrated Clang into much of the LLVM build system, for instance ‘llvm-config’. -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com

On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote: > On Jan 19, 2009, at 10:02 AM, Mike Stump wrote: > >> There isn't a good reason to create files called .dir in the >> installation directory. This patch fixes that. > > If we don't have this line, every build with do the makedir. And? $ time mkdir -p /bin real 0m0.002s user 0m0.000s sys 0m0.002s an extra mkdir

Hello, Tatu > Is that correct? I think it's just something to be aware of. Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov

On Oct 17, 2008, at 7:30 AM, Anton Korobeynikov wrote: > Hello, Tatu > >> Is that correct? I think it's just something to be aware of. > Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior? Please no flag. If we want to fix this problem, lets do it right. To me this

...that. Wouldn't it be slightly cleaner to mark the distinct objects in the LLVM intermediate representation? This would make the default case the one resulting in best code, and seems to me to follow the principle of structural equivalence of types (and values) used elsewhere. -- Dan Villiom Podlaski Christiansen, stud.scient. danchr at daimi.au.dk, danchr at gmail.com

Oscar, I be willing to donate some machine time to you. How about a 2 x 3GHz Dual Core Intel Xeon with 8GB? The question is how to get past the NAT. Email me privately if interested. Regards Mark Kromis On Nov 11, 2008, at 12:12 AM, Óscar Fuentes wrote: > Reports arrived indicating that the LLVM cmake-based build system is > lacking some OS X specific work, which seems to be the OS of

Hi, > gcc: gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) most likely the version of gcc you are using is broken. See http://llvm.org/docs/GettingStarted.html#brokengcc Ciao, Duncan.

Hi, I am just starting a new project. I found that the above script rejects Autoconf versions later than 2.59, whereas it ought to accept them, imho. I had to edit the scrip to be able to use it with Autoconf 2.61. Also, aclocal gave the following warning: /usr/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF /usr/share/aclocal/oaf.m4:4: run info '(automake)Extending

On Nov 12, 2009, at 11:43 AM, John Criswell wrote: > Dear LLVMers, > > I'm currently working on creating an alternate libLTO.so that will run > some whole-program analysis and transforms of mine during the final > linking of an executable. The idea is for it to link all of the > bitcode > files together, run the regular LTO passes, and then run my passes. > For

On Dec 4, 2009, at 2:49 PM, John Criswell wrote: >> If you are building llvm-gcc yourself, try, in this order: >> 1) sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/ >> libLTO.dylib >> >> 2) If you still get errors, try installing the libLTO.dylib from >> your LLVM build into /Developer/usr/lib. Make sure that if you're >> on a 64-bit

Dear LLVMers, I'm currently working on creating an alternate libLTO.so that will run some whole-program analysis and transforms of mine during the final linking of an executable. The idea is for it to link all of the bitcode files together, run the regular LTO passes, and then run my passes. For Linux, I should be able to get the Gold linker to load my libLTO.so instead of the standard

Reports arrived indicating that the LLVM cmake-based build system is lacking some OS X specific work, which seems to be the OS of choice for quite a few LLVM developers. I know there are sites out there that offer Linux shell accounts. Is there something similar for OS X, where building LLVM would be possible? A google search turned no solid results. Or would someone donate ssh access and approx.

Hi, When i wanted to build the llvm-gcc, i got the problem as following. ========================================================================================================================== cc1: /home/cllou/LLVM/llvm-2.4-dir/llvm-2.4/lib/Support/StringMap.cpp:177: void llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == V2 && "Didn't find

It seems that --enable-shared builds are not used by LLVM developers because the executables starts slowly. I guess this is related to the number of symbols the dynamic linker has to resolve. If we could reduce the symbols exported to those which are required, maybe the startup time would become bearable. One way of doing this is to add annotations to each public class and function (such as

Óscar Fuentes wrote: > It seems that --enable-shared builds are not used by LLVM developers > because the executables starts slowly. I guess this is related to the > number of symbols the dynamic linker has to resolve. If we could reduce > the symbols exported to those which are required, maybe the startup time > would become bearable. I think that premise needs to be retested. I