similar to: [LLVMdev] [PATCH] compiler-rt patch for clean build on Solaris 10 / x86

If this is not the proper place to report this problem, I apologize and would like to know the proper avenue. Information on compiler-rt is very scarce, and I have been unable to get block support on Linux any other way. I'm running X86_64 Ubuntu Linux, and I checked out the trunk of compiler-rt and built it according to the instructions on it's page, and ran the test suite. Three tests

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,

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

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

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

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

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

Hi all, compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week: 1. libraries: a) all libgcc replacement stuff moves from "/lib" to "/lib/core" (the name sucks, please suggest alternatives). Same for platform-specific code:

Hi Greg, On Fri, Mar 21, 2014 at 11:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi Alexey, > > CMAKE_PREFIX_PATH is a convenient mechanism for exposing prebuilt > install directories to a CMake build. It contains a colon-separated > list of paths. Each path points to a directory that contains > directory names that are meaningful to CMake, including

On Tue, Jul 8, 2014 at 2:44 PM, sgundapa <sgundapa at codeaurora.org> wrote: > No. CMake has different way of treating the .S files > Refer to http://www.cmake.org/Wiki/CMake/Assembler > > I have a patch which will make CMake treat the .S files as source files. > Let me guess, you should just call set_source_file_properties(<arm .S files> PROPERTIES LANGUAGE C)? >

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

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

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

Hello folks! I just wanted to give everyone a heads up about this. I spoke with Doug about this about a month ago and he told me to charge boldly forward, so the commits will be flying RSN. Essentially, the compiler-rt CMake build system is largely non-functional. Major portions are just commented out, I couldn't get it to actually build anything. Daniel has mostly been maintaining and

That's great. For multi targets compilerrt-rts, in old llvm 3.5 configuremakefileconfigure/makefile system, it will build multiple libs for each target on the target list pass to clang building. but since you said compiler-rt now require sysroot for proper headers, then I don't think multi libs can be built together any more. However, according to my knowledge, without compiler-rt, a

Context: I'm trying to implement support for ASan's unittest suite in CMake. This is ... quite challenging. I think I can get it to work with one significant caveat: it will require manual dependency management. None of the automatic header tracking. I think this is fine in some cases, and not so fine in other cases. Let me explain. It feels like these tests are really comprised of two

On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Mon, Jun 25, 2012 at 4:00 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> Context: I'm trying to implement support for ASan's unittest suite in >> CMake. This is ... quite challenging. >> >> I think I can get it to work with one significant

On 8 July 2014 19:47, Alexey Samsonov <vonosmas at gmail.com> wrote: > compiler-rt/lib/builtins/arm/*.S files are listed in arm_SOURCES variable, > and therefore should make it into the builtins static library on ARM. Don't > they? I assume so... But I'm not an expert in CMake.

On Tue, Jun 26, 2012 at 11:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, Jun 25, 2012 at 7:38 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > > > > > On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <kcc at google.com> > wrote: > >> > >> > >> > >> On Mon, Jun 25, 2012 at 4:00 PM,