similar to: [LLVMdev] [llvm-commits] [PATCH] BlocksRuntime updates for Linux

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

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

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

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,

There's an Apple internal bug for that. I've cloned it to Bugzilla as: <http://llvm.org/bugs/show_bug.cgi?id=5034> Implement __builtin_eh_return_data_regno() I can probably make the cmake configure stage fail up front if none of the supported mechanisms are found. I'll look at that. Thanks for the feedback! Shantonu Sent from my MacBook On Sep 22, 2009, at 9:01 PM,

Hi Jordan, I've committed my changes to hook up the BlocksRuntime/ subdirectory of compiler-rt, using CMake. The cmake build process is documented at <http://llvm.org/docs/CMake.html > More specifically, to use this support on FreeBSD, for example, you would do: 1) Install cmake (<http://www.cmake.org/>), add it to your PATH 2) Check out the source code for llvm and clang

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

The attached diff cleans up the BlocksRuntime/ directory of compiler- rt for better portability, eliminates compiler warnings, and adds support to the cmake build to install the results. More specifically, the changes: 1) Remove cmake-specific #define usage from the exported Block.h/ Block_private.h headers, since clients won't know what to set. These are moved into runtime.c as

On Sep 21, 2009, at 6:21 PM, Shantonu Sen wrote: > I've committed my changes to hook up the BlocksRuntime/ subdirectory > of compiler-rt, using CMake. > > The cmake build process is documented at <http://llvm.org/docs/CMake.html > > Whoops, looks like the presence of a CMakeFiles directory in the SRCROOT was screwing things up, even when I was in a build

I've reattached the patch to runtime.c, this time as output from svn instead of git. As the original git commit noted, it does the following: define OSAtomicCompareAndSwap(Long|Int) for non-Mac/Win32 systems if neither TARGET_OS_MAC or TARGET_OS_WINDOWS are defined, check to see if GCC atomic built-ins are available (and use them if they are). yours, Bobby On Sat, Sep 12, 2009 at 3:24 AM,

Hi Folks, The attached patches gets the Blocks runtime built and installed on my Linux system. Let me know if the patches are okay as is, or what I need to do to get them merged into compiler-rt. Thanks! yours, Bobby Powers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-define-OSAtomicCompareAndSwap-Long-Int-for-non-Mac-W.patch Type: text/x-patch Size:

Shantonu, I just wanted to verify that you used the llvm/autoconf/AutoRegen.sh script to regenerate configure. Is that correct? Thanks, Tanya On Feb 5, 2008, at 10:10 AM, Shantonu Sen wrote: > Some low-priority fixes to the build system.... These can probably > wait after 2.2 > > 1) The current configure script checks for gcc 3.x or later by > parsing "gcc

Hi, Here is an updated version of the patch using address space 257. Zoltan On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen <ssen at apple.com> wrote: > Maybe 257 would be better (or other unused), because of r70197, which gives > special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009,

Some low-priority fixes to the build system.... These can probably wait after 2.2 1) The current configure script checks for gcc 3.x or later by parsing "gcc --version" output and trying to tokenize it to find the major compiler version. This is pretty fragile and interacts poorly with compilers produced by vendors (like Apple) that modify this string to output target triple

I'm confused. libLTO takes bitcode files as input and creates a native object file as output. Why would libLTO create bitcode as output? If so, you're changing the existing API contract. Or are you creating an out-of-band bitcode file, in which case the linker would never see it. ld doesn't have bitcode support, it has libLTO support, and libLTO is what processes the bitcode.

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

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

Hello, The preferred way to do TLS is to use the thread_local keyword. There is x86-64 support for thread_local on ELF; if you need it for other targets, I recommend looking at adapting it. Dan On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > Hi, > > Here is an updated version of the patch using address space 257. > > Zoltan > > On Mon, May 4, 2009 at

Maybe 257 would be better (or other unused), because of r70197, which gives special behavior for <256 Shantonu Sen ssen at apple.com Sent from my Mac Pro On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > Hi, > > The attached patch adds support for accessing the FS segment > register using address space 255, similarly to the way the GS > segment register can be

Hi, If I'm writing a JIT, and want to access the TLS variables of the app containing the JIT, I can't use thread_local since that only works for variables declared in LLVM IL and/or managed by the ExecutionEngine. While this patch allows a JIT to generate the TLS accesses itself, if it knows the tls offset of the variable in question. Zoltan On Tue, May 5, 2009 at