search for: __sync_

I don't have much of substance to add, but I will say that I like the proposal (I too prefer Alternative A). When adding C11 atomic support for hexagon, I found it surprising that support for the __sync_* was implemented completely differently than the C11 atomics. On 1/27/2016 1:55 PM, James Knight via llvm-dev wrote: > Right now, the atomics implementation in clang is a bit of a mess. It > has three basically completely distinct code-paths: > > 1. There's the legacy __sync_* b...

Right now, the atomics implementation in clang is a bit of a mess. It has three basically completely distinct code-paths: There's the legacy __sync_* builtins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for implementing themselves if they need it). There's t...

...e Atomics implementation > > > I don't have much of substance to add, but I will say that I like the > proposal (I too prefer Alternative A). I also prefer alternative A. -Hal > When adding C11 atomic > support for hexagon, I found it surprising that support for the > __sync_* was implemented completely differently than the C11 > atomics. > > > On 1/27/2016 1:55 PM, James Knight via llvm-dev wrote: > > > > Right now, the atomics implementation in clang is a bit of a mess. It > has three basically completely distinct code-paths: > >...

llvm/lib/System/Atomic.cpp contains the call to __sync_val_compare_and_swap that lowers to the missing __sync_val_compare_and_swap_4 GCC intrinsic. The same file contains several other __sync_* calls and all these has to be implemented if we want to be able to compile llvm on linux/ARM with GCC versions below < 4.4 xerxes at labbserver:~/llvm$...

Why is his configure not catching this? It tests for the linkability of these functions on the target arch, and should be detecting their absence if that is actually the case. --Owen On Jul 1, 2009, at 12:50 AM, Xerxes Rånby wrote: > llvm/lib/System/Atomic.cpp contains the call to > __sync_val_compare_and_swap that lowers to the missing > __sync_val_compare_and_swap_4 GCC intrinsic. > > The same file contains several other __sync_* calls and all these has > to be implemented if we want to be able to compile llvm on linux/ARM > with GCC versions below < 4.4 > >...

On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote: > I think Clang should continue to duplicate this information, the same way > we duplicate target datalayout strings. Other than that, sure, we can let > LLVM expand IR operations to libcalls. I don't immediately see a problem > with that. Note that a libcall doesn't necessarily mean using locks. With

Nick Lewycky wrote: > 2009/6/30 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> > > Nick Lewycky wrote: > > I'm seeing this new build failure, starting some time yesterday on > ARM: > > Yes. It's just a matter of defining __sync_val_compare_and_swap_4: > > http://gcc.gnu.org/svn/gcc/trunk/gcc/config/arm/linux-atomic.c > > > The program is supposed to define it? LLVM doesn't directly call > __sync_val_compare_and_swap_4, so either the system headers #define > something else to it or gcc lowers...

Current precent in the codebase is the __sync_* libcalls. They have essentially the semantics you want, except that they're all seq_cst. On the LLVM side, I'd rather not have two ways to do the same thing, so I'd prefer to extend the existing mechanism. Adding 100 lines to RuntimeLibcalls.def seems a bit unfortunate, but I think...

...writing the triple. [r330169](http://reviews.llvm.org/rL330169). ## Other project commits * LLD now supports profile-guided section layout using the Call-Chain Clustering heuristic. [r330234](http://reviews.llvm.org/rL330234). * libcxxabi now uses `__libcpp_atomic_*` function calls rather than `__sync_*`. [r330162](http://reviews.llvm.org/rL330162). * The LLDB test suite is now run using Lit. [r330275](http://reviews.llvm.org/rL330275).

...home/nlewycky/llvm/Debug/lib -o > /home/nlewycky/llvm/Debug/bin/llvmc > /home/nlewycky/llvm/tools/llvmc/driver/Debug/Main.o -lplugin_llvmc_Base > -lplugin_llvmc_Clang \ > > -lpthread -ldl -lm > > /usr/bin/ld: /home/nlewycky/llvm/Debug/bin/llvmc: hidden symbol > `__sync_val_compare_and_swap_4' in > /usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced > by DSO > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: ld returned 1 exit status > > make[3]: *** [/home/nlewycky/llvm/Debug/bin...

Greetings everyone, I am working on Aarch64 LSE out-of-line atomics support in LLVM, porting this GCC series: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01034.html After local design experiments I've got some questions about upstream-suitable ways of implementation. More specifically: 1. Pass to expand atomics to library helper functions calls. These helpers test for the presence

...lib/aux: Ensure swap space prior to suspend to disk Emil Velikov (1): test/core_setmaster: new test for drop/set master semantics Guillaume Tucker (6): meson: add libatomic dependency gitlab-ci: add libatomic to docker images i915/gem_create: use atomic_* instead of __sync_* tests/sw_sync: use atomic_* instead of __sync_* gitlab-ci: add build for MIPS gitlab-ci: add tests for MIPS Imre Deak (31): tests/kms_properties: Fix upper bound of 'max bpc' range lib/rendercopy: Add AUX page table support tests/gem_render_copy: Adjust...

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an