similar to: [LLVMdev] Heads up: rewrite of CompilerRT's CMake build system

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, Attached is small patch (based of r122998 of compiler-rt), required for clean builds on Solaris 10 / x86 using clang 2.8. Please consider it for inclusion. Cheers, Joakim -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris_stdint.patch Type: application/octet-stream Size: 457 bytes Desc: not available URL:

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, 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)? >

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,

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

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

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

Hello I find the following email form internet, and I have the same problem, can you share your information about this issue? [Samba] ctdb issue: existing header for db_id 0xf2a58948 has larger RSN 1 than new RSN 1 in ctdb_persistent_store Nate Hardt nate at scalecomputing.com

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

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

On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > Are you going to move the unwind library there as part of the > reorganisation? > No. > > David > > On 11 Feb 2014, at 09:59, Alexey Samsonov <samsonov at google.com> wrote: > > > Hi all, > > > > compiler-rt is now not only a libgcc replacement for

FYI I will have an upload ready RSN. Where should I send it ? Matthew Vernon has offered to test my amd64 binaries. I will test the i386 packages myself. Ian.

Hi all ! ---------- I have problem with streaming... I use: Linux Fedora Core 4 - 2.6.17-1.2142_FC4smp Icecast 2.3.1 - installed from yum ices 0.4 - installed from source vlc 0.8.5 - installed from yum ---------- Im starting vlc like -

There's a couple of changes here, so to summarize: * Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on indenting * Store &mgr->up_req_recv.initial_hdr in a variable so we don't keep going over 80 character long lines * De-duplicate code for calling drm_dp_send_up_ack_reply() and getting the MSTB via it's GUID * Remove all of the duplicate calls to

I would still urge folks to consider keeping distinct functionality in separate places. Agreed, it makes more sense for the [language agnostic] unwinder to be in compiler-rt than libcxxabi -- but IMO it makes even more sense for it to be distinct. The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much

Which reduces indentation and makes this function more legible. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Signed-off-by: Lyude Paul <lyude at redhat.com> ---