similar to: [LLVMdev] undoing the pthread changes

I got two arguments the wrong way round, this is the fixed one On Wed, Oct 14, 2009 at 6:57 AM, Paul Davey <plmdvy at gmail.com> wrote: > Pthread search changes broke freebsd so they are coming out until something > better can be done > -------------- next part -------------- An HTML attachment was scrubbed... URL:

for evocallaghan he needed his configure.ac changes autogened. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091013/a6819944/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: auroraux.patch Type: text/x-patch Size: 9004 bytes Desc: not available URL:

This is a patch for the regenerated configure related files. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091013/eb1ed755/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: haiku.patch Type: text/x-patch Size: 11388 bytes Desc: not available URL:

support for triple in haiku it touches lib/Support/Triple.cpp and include/llvm/ADT/Triple.h -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091016/049eccbe/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: haikutriple.patch Type: application/octet-stream

Greatest appologies that had some cruft in it, let me send the cleaned one On Fri, Oct 16, 2009 at 12:45 AM, Paul Davey <plmdvy at gmail.com> wrote: > support for triple in haiku > > it touches lib/Support/Triple.cpp > and include/llvm/ADT/Triple.h > > > -------------- next part -------------- An HTML attachment was scrubbed... URL:

--emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com>wrote: > Hello everyone, > > I'm working on passing parameters for gold/LTO plug-in and could add this > one as well. > Just need an option name. Could anybody suggest one? > > Viktor > > ----- Original Message ----- > From: "Nick Lewycky" <nicholas at

--emit-llvm, if not conflict >>> Paul Davey <plmdvy at gmail.com> 10/30/2009 11:11 AM >>> --emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com> wrote: Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor

tail calls are only implemented for fastcall calling convention if i remeber right from my inquiries. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/e8f1dd2a/attachment.html>

No, As it worked fine before. I can't see the #if that goes with +#elif defined(__WIN32__) as you removed -#if TARGET_OS_MAC. Please go over your #if / #endif blocks and trail the #endif with a comment. I am willing to bet there is a problem there. Thanks for your time, Edward. 2009/9/23 Shantonu Sen <ssen at apple.com>: > Sounds like your system compiler doesn't support

Hi folks, So, various folks are in the process of porting Grand Central Dispatch to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev for mailing list discussion on the topic) and are making good progress, but one of the issues they're running into is support for Blocks in FreeBSD. On the one hand, they could try and back-port

On Nov 12, 2009, at 10:25 AM, Edward O'Callaghan wrote: > No, its up to them which backend they want to use. > Sounds like they think that GCC is super quick compared to LLVM. Looks > like another fud fart out of google to me. Edward, this is no place for comments like this. Evan > > 2009/11/12 Jon McLachlan <mclachlan at apple.com>: >> Any plans to make LLVM

I'm interested in contributing to LLVM, but I'm a rather bad C/C++ developer. I do most of my work in Ada and was wondering if there was a way to still contribute to something other than the Ada frontend.

Seems pretty clear cut to me. #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) && defined (HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG) ... #elif defined(__WIN32__) ... #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) && defined (HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG) ... #else #error unknown atomic compare-and-swap primitive #endif The problem isn't mismatched #if/#endif. The

screw that site, its useless info run by a linux gnu zealot. 2009/9/14 Chris Lattner <clattner at apple.com>: > On Sep 14, 2009, at 3:20 AM, Stefano Delli Ponti wrote: > >> http://www.phoronix.com/scan.php? >> page=article&item=apple_llvm_gcc&num=1 > > Unfortunately, they don't specify what flags are used, what > architecture is compiled for etc.

Breaks Builds on Solaris and AuroraUX with: bash-3.2$ make Scanning dependencies of target BlocksRuntime [ 1%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o /export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:77:2: error: #error unknown atomic compare-and-swap primitive /export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c: In

Clang does indeed built it with one warning. [ 55%] Building C object lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o /export/home/edward/lab/llvm/build/compiler-rt/lib/gcc_personality_v0.c:232:36: warning: implicit declaration of function '__builtin_eh_return_data_regno' is invalid in C99 [-Wimplicit-function-declaration] _Unwind_SetGR(context,

On Tue, Nov 10, 2009 at 11:24 AM, Patrick Kelly <kameo76890 at gmail.com>wrote: > I'm interested in contributing to LLVM, but I'm a rather bad C/C++ > developer. I do most of my work in Ada and was wondering if there was a way > to still contribute to something other than the Ada frontend. > Since I didn't elaborate, specifically I want to work on an Ada back-end.

LLVMers, The 2.6 code freeze is this friday, August 21, at 9pm PDT. All major changes should be checked into SVN at this time. Please monitor the buildbots closely for any failures. I ask you to be very cautious with what you commit to svn over the next few days. This is not the time to be adding experimental code :) Please help us keep LLVM as stable as possible over the next few days.

Good day, I been working on the CMake build system (which is nice and portable) + code clean ups over the whole Compiler-RT software suit. I recently added Blocks to the CMake build system but there is some ugly looking warnings I need to fix up in the Blocks code which I have not had time to look into yet. N.B. The CMake build system is not complete yet due to my lack of time, however I am still

Any plans to make LLVM work with Google's new language, Go? http://www.technewsworld.com/story/Go-Go-Google-Programming-Language-68622.html?wlc=1257974768&wlc=1258041607&wlc=1258047741