similar to: [LLVMdev] Hello!

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

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

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. 2009/11/12 Jon McLachlan <mclachlan at apple.com>: > Any plans to make LLVM work with Google's new language, Go? > >

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.

Good day all, Initial Ada bindings have been introduced for the LLVM 2.6 release. Unfortunately no one was able/had time to help me better integrate it into the LLVM build system. Thus, It has been left with a GPR Ada project file for building the bindings, anyone using the Ada bindings will know what this is and how to handle it. However, in future as these bindings improve/progress. We should

Hi Edward, > Initial Ada bindings have been introduced for the LLVM 2.6 release. > Unfortunately no one was able/had time to help me better integrate it > into the LLVM build system. Thus, It has been left with a GPR Ada > project file for building the bindings, anyone using the Ada bindings > will know what this is and how to handle it. does this mean the bindings only work with

Hello. How are the things going with the llvm-gcc for SPARC and Solaris OS? I have discovered recently the fact, that the code is still in the "patches welcome" stage and is far even from being successfully built on SPARC. I would like to know, if anyone maintaining this code, what is the current to-do list, etc. I would like to offer my help for gcc front-end on SPARC project. --

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.

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

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.

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

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

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,

Sounds like your system compiler doesn't support gcc-style builtin atomics. Please use a different compiler? Shantonu Sent from my MacBook On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote: > Breaks Builds on Solaris and AuroraUX with: > > bash-3.2$ make > Scanning dependencies of target BlocksRuntime > [ 1%] Building C object

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:

Török Edwin wrote: > On 2009-11-14 00:57, John Criswell wrote: > >> Dear LLVMers, >> >> We are happy to announce an alpha release of the SAFECode compiler. It >> is now available for download from the LLVM public Subversion >> repository. SAFECode uses a set of analysis passes and program >> transformations to provide strong memory safety

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

Good day Tanya, I would just like to clarify this for myself and a few other people who maybe wondering, Does this code freeze apply to; * Clang. * Compiler-RT. Thanks for your time, Best Regards, Edward O'Callaghan. 2009/8/17 Tanya Lattner <lattner at apple.com>: > LLVMers, > > The 2.6 code freeze is this friday, August 21, at 9pm PDT. > > All major changes should

The Blocks language and implementation specifications are checked into clang/docs. More generally, on Mac OS X, the blocks runtime is linked into the C library ("libSystem"), and available to the entire OS. Clients that create blocks may implicitly get compiler-generated calls to some of the runtime functions, and the developer may also make explicit calls to, e.g.,