Re: [PATCH] libitm/x86: Correct offsets of __private_tm and pointer_guard

On Wed, 2018-05-30 at 07:54 -0700, H.J. Lu wrote: > In glibc, sysdeps/i386/nptl/tls.h has > > typedef struct > { > void *tcb;/* Pointer to the TCB. Not necessarily the >thread descriptor used by libpthread. */ > dtv_t *dtv; > void *self;

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 19:32 +, Ruslan Nikolaev wrote: > > > But we're not talking about that special case of 128b types here. The > > majority of synchronization doesn't need more than machine word size. > Then why do you worry about read-only access for 128b types? (it is a special > case

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 17:29 +, Ruslan Nikolaev wrote: > > > > Consider a producer-consumer relationship between two processes where > > the producer doesn't want to wait for the consumer. For example, the > > producer could be an application that's being traced, and the consumer > > is a

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote: > On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: > > > > And all this mess to accommodate almost non-existent case when someone > > wants to use atomic_load on read-only memory for wide types, in which no > >

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote: > > 3) Torvald pointed out further considerations such as users expecting > > lock-free atomic loads to be faster than stores. > > Is it even true? Is it faster to use some global lock (implemented through > RMW) than a single

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote: > the solutions is to add a language extension I think this only needs a library interface, at least when we're just considering the __atomic builtins. On the C/C++ level, it might amount to just another atomic type, which only has a CAS

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote: > But, of course, it is kind of annoying that double-width types (and that also > includes potentially 64-bit on some 32-bit processors, e.g. i586 also has > cmpxchg8b and no official way to read atomically otherwise) need special

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote: > The way to fix this in AArch64 if there is a > guarantee from the standard that there are no problems with read-only > locations is to implement the change in libatomic. Even though the standard doesn't specify read-only memory, I

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote: > Torvald, I definitely do not want to insist on this design choice, but it > makes sense to at least seriuously consider it given the concerns I > described. And especially because IFFUNC in libatomic already redirects to >

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 18:55 +, Ruslan Nikolaev via gcc wrote: > Torvald, thank you for your output. See my response below. > > On Monday, February 26, 2018 1:35 PM, Torvald Riegel <trie...@redhat.com> > wrote: > > > ... does not imply this latter statemen

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 07:24 +, Ruslan Nikolaev via gcc wrote: > Alexander, > Thank you for your comments. Please see my response below. I definitely do > not want to fight for or against this change in gcc, but there are definitely > legitimate concerns to consider. I think, it would really

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 08:50 +0300, Alexander Monakov wrote: > > For these reasons, it may be a good idea if GCC folks reconsider past > > decision. And just to clarify: if mcx16 (x86-64) is not specified during > > compilation, it is totally OK to redirect to libatomic, and there make the > >

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 14:53 +, Ruslan Nikolaev via gcc wrote: > Thank you for more comments, my response is below. > > > > On Mon, 26 Feb 2018, Szabolcs Nagy wrote:> > > rmw load is only valid if the implementation can > > guarantee that atomic objects are never read-only. > But per

Re: [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required

On Sun, 2018-01-07 at 20:55 +, Mike Crowe wrote: > This patch series was originally submitted back in September at > https://gcc.gnu.org/ml/libstdc++/2017-09/msg00083.html which ended up > as https://patchwork.ozlabs.org/cover/817379/ . The patches received > no comments at all, which may mean

Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

On Tue, 2018-01-09 at 17:54 +, Mike Crowe wrote: > On Tuesday 09 January 2018 at 13:50:54 +, Jonathan Wakely wrote: > > On 07/01/18 20:55 +, Mike Crowe wrote: > > > The futex system call supports waiting for an absolute time if > > > FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT.

Re: atomic_thread_fence() semantics

On Fri, 2017-10-20 at 18:46 +0300, Alexander Monakov wrote: > On Fri, 20 Oct 2017, Torvald Riegel wrote: > > On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote: > > > On Thu, 19 Oct 2017, Andrew Haley wrote: > > > > No, you did not. This lo

Re: atomic_thread_fence() semantics

On Fri, 2017-10-20 at 12:47 +0200, Torvald Riegel wrote: > On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote: > > Hi. > > > > I have this code: > > > > #include > > > > int ready; > > int message; > > > > void send_x4711(i

Re: atomic_thread_fence() semantics

On Thu, 2017-10-19 at 13:18 +0100, Andrew Haley wrote: > On 19/10/17 13:10, Jonathan Wakely wrote: > > There are no atomic operations on atomic objects here, so the fence > > doesn't synchronize with anything. > > Really? This seems rather unhelpful, to say the least. > > An atomic release

Re: atomic_thread_fence() semantics

On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote: > On Thu, 19 Oct 2017, Andrew Haley wrote: > > On 19/10/17 12:58, Mattias Rönnblom wrote: > > > Did I misunderstand the semantics of > > > atomic_thread_fence+memory_order_release? > > > > No, you did not. This looks like a bug.

Re: atomic_thread_fence() semantics

On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote: > Hi. > > I have this code: > > #include > > int ready; > int message; > > void send_x4711(int m) { > message = m*4711; > atomic_thread_fence(memory_order_release); > ready = 1; > } > > When I compile it with GCC 7.2

Re: GCC extension for atomic access to members

On Tue, 2017-09-19 at 15:36 +0200, Florian Weimer wrote: > On 09/19/2017 03:32 PM, Torvald Riegel wrote: > > On Tue, 2017-09-19 at 07:19 +0200, Florian Weimer wrote: > >> On 09/18/2017 10:07 PM, Torvald Riegel wrote: > >>> On Mon, 2017-09-18 at 14:19 +0200, Floria

Re: GCC extension for atomic access to members

On Tue, 2017-09-19 at 07:19 +0200, Florian Weimer wrote: > On 09/18/2017 10:07 PM, Torvald Riegel wrote: > > On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: > >> I would like to see the GCC project to document that if the address of a > >> member is take

Re: GCC extension for atomic access to members

On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: > I would like to see the GCC project to document that if the address of a > member is taken, this does not constitute an access to the object as a > whole. > > That is, in the following code: > > #include > > struct S { >_Atomic

Re: RFC: C extension to support variable-length vector types

On Thu, 2017-08-03 at 17:32 +0200, Torvald Riegel wrote: > On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: > > Torvald Riegel <trie...@redhat.com> writes: > > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: > > >> (

Re: RFC: C extension to support variable-length vector types

On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: > Torvald Riegel <trie...@redhat.com> writes: > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: > >> (1) Does the approach seem reasonable? > >> > >> (2) Would it be acc

Re: RFC: C extension to support variable-length vector types

On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: > (1) Does the approach seem reasonable? > > (2) Would it be acceptable in principle to add this extension to the > GCC C frontend (only enabled where necessary)? > > (3) Should we submit this to the standards committee? I

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote: > __atomic_load on ARM appears to be ok as well > > except for > > __atomic_load_di which should really be the ldrexd / strexd loop but we > could ameliorate that similar to your option 3b. This uses just ldrexd now, and thus is

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Thu, 2017-02-02 at 13:58 +0100, Thomas Schwinge wrote: > > The other failures I saw didn't seem atomics related > > (eg, openacc) > > I suppose you're testing without nvptx offloading -- which failures do > you see for OpenACC testing? (There shouldn't be any for host fallback > testing.)

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Thu, 2017-02-02 at 14:48 +, Ramana Radhakrishnan wrote: > On 30/01/17 18:54, Torvald Riegel wrote: > > This patch fixes the __atomic builtins to not implement supposedly > > lock-free atomic loads based on just a compare-and-swap operation. > > > > If there is no

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Mon, 2017-01-30 at 19:54 +0100, Torvald Riegel wrote: > This patch fixes the __atomic builtins to not implement supposedly > lock-free atomic loads based on just a compare-and-swap operation. After an off-list OK by Jakub, I have committed this as r245098. Jakub will take care of the

[PATCH] Fix __atomic to not implement atomic loads with CAS.

code inlined. Jakub: If this is OK for GCC 7, can you please take care of the OpenMP bits and commit this? Changelog entries are in the commit message. If others could test on other hardware, this would also be appreciated. commit 1db13cb386e673d5265bcaf2d70fc25dda22e5fd Author: Torvald Riegel

Re: -mcx16 vs. not using CAS for atomic loads

On Tue, 2017-01-24 at 13:06 -0800, Richard Henderson wrote: > On 01/24/2017 01:08 AM, Torvald Riegel wrote: > > Unless HW transactions are guaranteed to succeed for scenarios that are > > sufficient for the atomics, HTM won't help because we'd have to consider > > the worst-c

Re: -mcx16 vs. not using CAS for atomic loads

On Fri, 2017-01-20 at 09:55 -0800, Richard Henderson wrote: > On 01/19/2017 10:23 AM, Torvald Riegel wrote: > > I think I prefer Option 3b as the short-term solution. It does not > > break programs (except the __atomic_always_lock_free assertion scenario, > > but that's like

-mcx16 vs. not using CAS for atomic loads

If using -mcx16 (directly or indirectly) today, then cmpxchg16b is used to implement atomic loads too. I consider this a bug because it can result in a store being issued (e.g., when loading from a read-only page, or when trying to do a volatile atomic load), and because it can increase

Re: GCC libatomic ABI specification draft

On Thu, 2016-12-22 at 11:37 -0600, Segher Boessenkool wrote: > On Thu, Dec 22, 2016 at 03:28:56PM +0100, Ulrich Weigand wrote: > > However, there still seems to be a problem, but this time related to > > alignment issues. We do have the 16-byte atomic instructions, but they > > only work on

Re: GCC libatomic ABI specification draft

On Wed, 2017-01-18 at 14:23 -0800, Richard Henderson wrote: > On 01/17/2017 09:00 AM, Torvald Riegel wrote: > > I think the ABI should set a baseline for each architecture, and the > > baseline decides whether something is inlinable or not. Thus, the > > x86_64 ABI would mak

[committed] libitm: Disable TSX on processors on which it may be broken.

This fix follows the same approach that glibc uses to disable TSX on processors on which it is broken. TSX can also be disabled through a microcode update on these processors, but glibc consensus is that it cannot be detected reliably whether the microcode update has been applied. Thus, we just

Re: GCC libatomic ABI specification draft

On Thu, 2016-11-17 at 12:12 -0800, Bin Fan wrote: > On 11/14/2016 4:34 PM, Bin Fan wrote: > > Hi All, > > > > I have an updated version of libatomic ABI specification draft. Please > > take a look to see if it matches GCC implementation. The purpose of > > this document is to establish an

Re: GCC libatomic ABI specification draft

On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote: > On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote: > > Hi Szabolcs, > > > > > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote: > > > > > > On 17/11/16 20:12, Bin Fan wrote: > > >> > > >> Although

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

On Wed, 2016-09-21 at 16:56 +0200, Florian Weimer wrote: > Torvald, would it be possible to align mutexes internally on hppa, to > avoid the 16-byte alignment of the entire struct (that is, store a > pointer to the actual mutex object, which points to a sub-region of > the struct which is suitably

Re: [PATCH] Partially improve scalability of the unwinder (PR libgcc/71744)

On Thu, 2016-09-15 at 06:05 -0700, Ian Lance Taylor wrote: > Jakub Jelinek writes: > > > 2016-09-15 Jakub Jelinek > > > > PR libgcc/71744 > > * unwind-dw2-fde.c (ATOMIC_FDE_FAST_PATH): Define if __register_frame* > > is not the primary registry

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: > Pass build time CC make var down to dejagnu so the sysroot > is set correctly when gcc is built with --with-build-sysroot. > > libitm/ > 2016-08-24 Szabolcs Nagy > > PR testsuite/71931 > *

Re: Implementing atomic load as compare-and-swap for read-only memory

On Fri, 2016-06-03 at 13:46 +0100, Kyrill Tkachov wrote: > Hi Jakub, Torvald, > > On 03/06/16 13:32, Jakub Jelinek wrote: > > On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote: > >> And that would be fine, IMO. If you can't even load atomically, doi

Re: Implementing atomic load as compare-and-swap for read-only memory

On Fri, 2016-06-03 at 14:32 +0200, Jakub Jelinek wrote: > On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote: > > And that would be fine, IMO. If you can't even load atomically, doing > > something useful with this type will be hard except in special cases. > &

Re: Implementing atomic load as compare-and-swap for read-only memory

On Fri, 2016-06-03 at 12:03 +0200, Jakub Jelinek wrote: > On Fri, Jun 03, 2016 at 10:34:15AM +0100, Kyrill Tkachov wrote: > > expand_atomic_load in optabs.c tries to expand a wide atomic load using an > > atomic_compare_and_swap > > with the comment saying that sometimes a redundant harmless

Re: SafeStack proposal in GCC

On Mon, 2016-05-09 at 12:25 -0700, Ian Lance Taylor wrote: > On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: > > > > The *context APIs are deprecated and I'm not sure they're worth > > supporting with this. It would be a good excuse to get people to stop > > using them. > >

Re: [PATCH] PR libitm/70456: Allocate aligned memory in gtm_thread operator new

On Sat, 2016-04-02 at 09:25 -0700, H.J. Lu wrote: > On Wed, Mar 30, 2016 at 5:34 AM, H.J. Lu wrote: > > Since GTM::gtm_thread has > > > > gtm_thread *next_thread __attribute__((__aligned__(HW_CACHELINE_SIZE))); > > > > GTM::gtm_thread::operator new should allocate aligned

Re: Re: Adding a new thread model to GCC

On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote: > Yes I learnt those *ByAddress* functions a few months ago and was shocked > that Microsoft had plagiarized futex from Linux. > As you have pointed out already, those APIs are only available on Windows 8 > and later. Yes. On Windows 8, given

Re: Adding a new thread model to GCC

On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote: > Hi all, > > The 'win32' thread model of gcc has been there since long long ago, being > compatible with very old Windows versions, also having a number of drawbacks: > 0) its implementation is very inefficient, and > 1) its mutexes and

Re: [PING 2, PATCH] libitm: Introduce target macro TARGET_BEGIN_TRANSACTION_ATTRIBUTE.

On Wed, 2016-03-02 at 07:36 +0100, Dominik Vogt wrote: > On Mon, Feb 01, 2016 at 02:18:48PM +0100, Dominik Vogt wrote: > > The attached patch adds the a target specific attribute via the > > new target macro TARGET_BEGIN_TRANSACTION_ATTRIBUTE to the > > function begin_transaction(). S/390 uses

Re: Importance of transformations that turn data dependencies into control dependencies?

On Fri, 2016-02-26 at 20:10 +0100, Torvald Riegel wrote: > On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote: > > On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel <trie...@redhat.com> wrote: > > > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > > >

Re: Importance of transformations that turn data dependencies into control dependencies?

On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote: > On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel <trie...@redhat.com> wrote: > > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > >> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel <trie...@redhat.

Re: Importance of transformations that turn data dependencies into control dependencies?

On Thu, 2016-02-25 at 18:33 +0100, Torvald Riegel wrote: > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel <trie...@redhat.com> wrote: > > > I'd like to know, based on the GCC experience, how important we cons

Re: Importance of transformations that turn data dependencies into control dependencies?

On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel <trie...@redhat.com> wrote: > > I'd like to know, based on the GCC experience, how important we consider > > optimizations that may turn data dependencies of

Importance of transformations that turn data dependencies into control dependencies?

I'd like to know, based on the GCC experience, how important we consider optimizations that may turn data dependencies of pointers into control dependencies. I'm thinking about all optimizations or transformations that guess that a pointer might have a specific value, and then create

Re: [PATCH] libitm: Fix HTM fastpath.

On Fri, 2016-01-08 at 12:07 +0100, Torvald Riegel wrote: > This patch fixes a thinko in the HTM fastpath implementation. In a > nutshell, we also need to monitor the HTM fastpath control (ie, > htm_fastpath) variable from within a HW transaction on the HTM fastpath, > so th

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote: > Torvald, > > Now that I can bootstrap on darwin, I have found the following failure for > libitm.c++/libstdc++-safeexc.C > > /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: > unsafe function call

Re: SH runtime switchable atomics - proposed design

On Wed, 2016-01-20 at 20:22 -0500, Rich Felker wrote: > On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote: > > Do you have plans to add other atomic operations (like > > arithmetic)? > > No, at least not in musl. From musl's perspective cas is the main one > that's used anyway. But even

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

fe function call 'std::underflow_error::underflow_error(const string&)' > within atomic transaction > throw T (what); > ^ Does this patch fix it (ie, mark the test unsupported)? commit 259c0cf27d0a88eecc90af1aa500f88f6108cb04 Author: Torvald Riegel <trie...@redhat.com>

[PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

ined would be > nice. Here's the patch I prepared (which indeed includes a comment). OK for trunk? I'm not quite sure whether this qualifies as a regression, but having an additional test that now fails is one I guess. commit 0323fed14832e5744cbc63bcfeeb6728f7f13394 Author: Torvald Riegel <trie

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Thu, 2016-01-21 at 18:12 +, Pedro Alves wrote: > On 01/21/2016 06:06 PM, Mike Stump wrote: > > On Jan 21, 2016, at 9:29 AM, Dominique d'Humières > > wrote: > >> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } } > > > > A comment to hint that this has

Re: [PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

On Thu, 2016-01-21 at 18:26 +, Jonathan Wakely wrote: > On 21/01/16 10:19 -0800, Mike Stump wrote: > >On Jan 21, 2016, at 10:15 AM, Torvald Riegel <trie...@redhat.com> wrote: > >> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote: > >>> On Jan 21, 2016, at

[PATCH][committed] libitm: Remove dead code.

I missed dead code when I removed the cacheline stuff. local_type_traits hasn't been updated either, apparently leading to bootstrap issues. So we just remove more dead code. Tested fine on x86_64-linux. Committed. commit c608b69c3c49c7d29033faf328fd4d117f31fd9f Author: Torvald Riegel <t

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

Jon, okay from your side if Darwin testing succeeds? commit 6987f84f278d2cbf5b828a8c81c1be84b292b1af Author: Torvald Riegel <trie...@redhat.com> Date: Tue Jan 19 18:36:14 2016 +0100 libstdc: Use weak alias instead of just alias in TM support. PR libstdc++/69310 * src/c++11/

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote: > On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel <trie...@redhat.com> wrote: > > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote: > >> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek <ja...@redhat.com>

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Mon, 2016-01-18 at 14:54 +0100, Torvald Riegel wrote: > On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote: > > On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel <trie...@redhat.com> wrote: > > > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote: > > >

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

and I suppose that it should work on AIX too (but I haven't tested). Is it harmless if gnu.pre lists symbols that we don't provide? Thoughts? commit 9008d4a610dccb5ec47f9c1e506492b8615a36fd Author: Torvald Riegel <trie...@redhat.com> Date: Sun Jan 17 19:21:13 2016 +0100 libstdc++: Fix usage of

Re: [PATCH] libstdc++: Fix static_assert.

On Sun, 2016-01-17 at 17:03 +, Jonathan Wakely wrote: > On 17 January 2016 at 17:01, Jonathan Wakely wrote: > > On 16 January 2016 at 22:47, Torvald Riegel wrote: > >> This adds a missing string argument to a call to static_assert, thus not > >> making it

[PATCH][committed] libitm: Ensure proxy privatization safety.

Author: Torvald Riegel <trie...@redhat.com> Date: Fri Nov 27 22:59:07 2015 +0100 libitm: Ensure proxy privatization safety. * method-gl.cc (gl_wt_dispatch::trycommit): Ensure proxy privatization safety. * method-ml.cc (ml_wt_dispatch::trycommit): Likewise. *

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Sat, 2016-01-16 at 10:57 +0100, Dominique d'Humières wrote: > > Addressed these, fixed a problem with using GLIBCXX_WEAK_DEFINITION > > (which is only set on Darwin despite the generic-sounding name -- so > > just use __attribute__((weak)) directly), and also updated > > testsuite_abi.cc so

[PATCH] libstdc++: Fix static_assert.

This adds a missing string argument to a call to static_assert, thus not making it depend on c++1z extensions. This fixes the build breakage on mingw introduced in 232454. Tested on x86_64-linux. OK? commit 7659ab483954a15c8143f6b1b9d135159a2ecc67 Author: Torvald Riegel <trie...@redhat.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Sat, 2016-01-16 at 14:35 +0100, Jakub Jelinek wrote: > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote: > > stage1 libstdc++ builds just fine. the problem is stage2 configure > > fails due to missing ITM_xxx symbols when configure tries to compile > > and run conftest programs.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On Thu, 2016-01-14 at 17:58 +, Jonathan Wakely wrote: > On 07/01/16 17:47 +0100, Torvald Riegel wrote: > >The attached patch makes some exceptions transaction-safe, as require by > >the Transactional Memory TS. I believe I addressed all feedback for the > >previous

[PATCH][committed] libitm: Fix privatization safety interaction with serial mode.

snapshot most recent (or abort if it cannot) so that the still-active transactions that the upgrader waits for are not waiting in turn for the upgrader to update its snapshot. Tested on x86_64-linux. Committed as r232322. 2016-01-13 Torvald Riegel <trie...@redhat.com> * begin

[PATCH][committed] libitm: Fix seq-cst MOs/fences in rwlock.

optimizations of concurrent code. Tested on x86_64-linux. Committed as r232353. 2016-01-13 Torvald Riegel <trie...@redhat.com> * beginend.cc (gtm_thread::trycommit): Fix seq_cst fences. * config/linux/rwlock.cc (gtm_rwlock::write_lock_generic): Likewise. (gtm_rwlock::write_

[PATCH][committed] libitm: Remove dead code and data.

This removes code and data members that have not been used for quite a while now. The user-visible benefit is 8MB less space overhead if libitm is used. Tested on x86_64-linux and committed as r232275. 2016-01-12 Torvald Riegel <trie...@redhat.com> * libitm_i.h (gtm_mask

[PATCH] libitm: Fix HTM fastpath.

move htm_fastpath into the serial lock so that a HW transaction only needs one cacheline of HTM capacity to monitor both htm_fastpath and check that no non-HW-transaction is currently running. Tested on x86_64-linux. 2016-01-08 Torvald Riegel <trie...@redhat.com> * beginend.c

[PATCH v2] libstdc++: Make certain exceptions transaction_safe.

support and bugfixes on the compiler side). Tested on x86_64-linux and x86-linux. OK? 2016-01-07 Torvald Riegel <trie...@redhat.com> * include/bits/basic_string.h (basic_string): Declare friends. * include/bits/c++config (_GLIBCXX_TXN_SAFE, _GLIBCXX_TXN_SA

Re: [PATCH][WIP] libstdc++: Make certain exceptions transaction_safe.

On Wed, 2015-12-16 at 21:05 +, Jonathan Wakely wrote: > Sorry for the delay finishing this review, some of the code kept > melting my brain ;-) I know what you mean :) Thanks for the review! > On 14/11/15 20:45 +0100, Torvald Riegel wrote: > >diff --git a/libstdc++-v3/config/

Re: [patch] libstdc++/68921 add timeout argument to futex(2)

On Tue, 2015-12-15 at 18:46 +, Jonathan Wakely wrote: > This fixes a missing argument to the futex syscall. > > Tested powerpc64le-linux. This needs to be fixed for gcc-5 and trunk. > OK. Thanks!

[COMMITTED] libitm: Use multiplicative hashing in the multi-lock TM method.

. In-depth performance testing in another implementation similar to libitm has been done before, see the URL cited in the code's comments. commit 7c6d5c7221b85fd82bcb8c59c90ae39b14883b98 Author: Torvald Riegel <trie...@redhat.com> Date: Thu Nov 26 16:52:04 2015 +0100 libitm: Use multiplicative h

[COMMITTED] libitm: Fix recent changes to allocations log.

74c5fd924fe3e8d6bececce209d00bf0523bb4dc Author: Torvald Riegel <trie...@redhat.com> Date: Sun Nov 22 21:54:24 2015 +0100 libitm: Fix recent changes to allocations log. libitm/ * libitm_i.h (gtm_alloc_action): Remove union. * testsuite/libitm.c/alloc-1.c: New. diff --git a/libitm/libi

Re: [PATCH] Transactional Memory: Support __cxa_free_exception and fix exception handling.

On Thu, 2015-11-19 at 11:18 -0600, Peter Bergner wrote: > On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote: > > Tested using the libitm testsuite on x86_64-linux. > > Tested on powerpc64le-linux with no regressions and I confirmed > the new eh-5.C test case passes.

[PATCH] Transactional Memory: Support __cxa_free_exception and fix exception handling.

): New. (gtm_thread::init_cpp_exceptions): Define. (_ITM_cxa_allocate_exception, _ITM_cxa_throw): Adapt. (_ITM_cxa_begin_catch, _ITM_cxa_end_catch): Likewise. (gtm_thread::revert_cpp_exceptions): Likewise. commit 23bd34e3c8028a12705a47d13a4c7aa36bfeca60 Author: Torvald

[PATCH][WIP] libstdc++: Make certain exceptions transaction_safe.

nted-out calls to _ITM_setAssociatedException in the code, which exist to show how we plan to support transaction cancellation through exceptions (which needs some more libitm support and bugfixes on the compiler side). commit e81080a01ab0daf2949a400c1a2d5077d37ba515 Author: Torvald Riegel <trie...

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

On Wed, 2015-11-11 at 15:04 +, Szabolcs Nagy wrote: > On 10/11/15 18:29, Torvald Riegel wrote: > > On Tue, 2015-11-10 at 17:26 +, Szabolcs Nagy wrote: > >> On 09/11/15 00:19, Torvald Riegel wrote: > >>> I've not yet created tests for the fu

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

On Tue, 2015-11-10 at 17:26 +, Szabolcs Nagy wrote: > On 09/11/15 00:19, Torvald Riegel wrote: > > Hi, > > > > I'd like to summarize the current state of support for the TM TS, and > > outline the current plan for the work that remains to complete the > >

[PATCH] libitm: Support __cxa_free_exception and fix exception handling.

0a67dc5a13fd17a24fc667a251d000a73cd5159e Author: Torvald Riegel <trie...@redhat.com> Date: Tue Nov 3 15:38:22 2015 +0100 Support __cxa_free_exception and fix exception handling. diff --git a/libitm/beginend.cc b/libitm/beginend.cc index c3ed11b..86f7b39 100644 --- a/libitm/beginend.cc +++ b/

[PATCH v2] libitm: Support sized delete.

This patch supports the sized variants of operator delete. Some change compare to v1. Tested on x86_64-linux. commit df00a283f2e37bd3c69f37783fa81dde7ccf1f94 Author: Torvald Riegel <trie...@redhat.com> Date: Thu Oct 29 18:52:20 2015 +0100 Support sized delete. Thi

State of support for the ISO C++ Transactional Memory TS and remanining work

Hi, I'd like to summarize the current state of support for the TM TS, and outline the current plan for the work that remains to complete the support. I'm aware we're at the end of stage 1, but I'm confident we can still finish this work and hope to include it in GCC 6 because: (1) most of the

Re: [PATCH] libitm: Support sized delete.

On Fri, 2015-10-30 at 10:19 -0700, Richard Henderson wrote: > > #define _ZnwX S(_Znw,MANGLE_SIZE_T) > > #define _ZnaX S(_Zna,MANGLE_SIZE_T) > > +#define _ZdlPvXS(_ZdlPv,MANGLE_SIZE_T) > > #define _ZnwXRKSt9nothrow_t

Re: [PATCH] libitm: Support sized delete.

On Thu, 2015-10-29 at 12:38 -0700, Richard Henderson wrote: > On 10/29/2015 11:19 AM, Torvald Riegel wrote: > > diff --git a/libitm/libitm.map b/libitm/libitm.map > > index 21bcfdf..7fc9a41 100644 > > --- a/libitm/libitm.map > > +++ b/libitm/libitm.map > >

[PATCH] libitm: Support sized delete.

for that and use non-sized dlete under the covers.) 2015-10-29 Torvald Riegel <trie...@redhat.com> * alloc_cpp.cc (_ZdlPvX, _ZdlPvXRKSt9nothrow_t, _ZGTtdlPvX, _ZGTtdlPvXRKSt9nothrow_t, delsz_opnt): New. * libitm.map: Add _ZGTtdlPvX and _ZGTtdlPvXRKSt9nothrow_t. * libi

Re: [PATCH, rs6000] Add memory barriers to tbegin, tend, etc.

On Fri, 2015-10-09 at 11:52 -0500, Peter Bergner wrote: > On Fri, 2015-10-09 at 16:41 +0200, Torvald Riegel wrote: > > On Thu, 2015-09-03 at 16:58 -0500, Peter Bergner wrote: > >> +Note that the semantics of the above HTM builtins are required to mimic > >> the &

Re: [PATCH, rs6000] Add memory barriers to tbegin, tend, etc.

Sorry for the much delayed response. I've been sick and am slowly catching up. On Thu, 2015-09-03 at 16:58 -0500, Peter Bergner wrote: > On a glibc thread discussing this issue, Torvald also asked that I add > documention describing the memory consistency semantics the HTM instructions > should

Re: [gomp4.1] Doacross library implementation

On Thu, 2015-09-24 at 20:32 +0200, Jakub Jelinek wrote: > Torvald, can you please have a look at it, if I got all the atomics / memory > models right? More detailed comments below, but in general, I'd really suggest to add more code comments for the synchronization parts. In the end, the level

Re: RFC: PATCH for front end parts of C++ transactional memory TS

On Fri, 2015-10-02 at 14:13 -0400, Jason Merrill wrote: > The patch also doesn't attempt to do anything about the library. The > second patch sets transaction_safe on various built-ins, but without the > library support this just means references to undefined symbols. For some of the builtins,

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Mon, 2015-08-17 at 13:16 +0200, Gleb Fotengauer-Malinovskiy wrote: On Sun, Aug 16, 2015 at 07:35:17PM +0200, Torvald Riegel wrote: On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote: 2015-05-06 Gleb Fotengauer-Malinovskiy gle...@altlinux.org PR libitm/61164

  1   2   3   4   5   >