m
fast paths on your architectures, or would you like to see any changes?
Torvald
commit 9329bd4504d13d415542d93418157d588b599b4e
Author: Torvald Riegel
Date: Wed Aug 21 11:40:54 2013 +0200
Add custom HTM fast path for RTM on x86_64.
* libitm_i.h (gtm_thread): Assign an asm
On Wed, 2013-08-21 at 10:14 -0700, Andi Kleen wrote:
> Torvald Riegel writes:
> > +#endif
> > leaq8(%rsp), %rax
> > - subq$56, %rsp
> > - cfi_def_cfa_offset(64)
> > + subq$64, %rsp
> > + cfi_def_cfa_offset(72)
>
> I don'
On Wed, 2013-08-21 at 19:41 +0200, Andi Kleen wrote:
> > That's true for x86, but it seems that for s390, we can't easily put the
> > xbegin/tbegin into the C++ code because of floating point register
> > save/restore issues. The added complexity on the x86 side seemed to be
> > a reasonable price
tatic gtm_rwlock serial_lock
> > +__asm__("gtm_serial_lock");
> > +#endif
>
> Now that we have 3 copies of this, we should simplify things. E.g.
>
> #ifdef __USER_LABEL_PREFIX__
> # define UPFX1(X) #X
> # define UPFX UPFX1(__USER_LABEL_PREFIX__
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> > + /* Store edi for future HTM fast path retries. We use a stack slot
> > + lower than the jmpbuf so that the jmpbuf's rip field will overlap
> > +
On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
> On 08/22/2013 02:57 PM, Torvald Riegel wrote:
> > On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> >> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> >>> + /* Store edi for future HTM fast path
On Fri, 2013-08-30 at 16:49 +0200, Rainer Orth wrote:
> Torvald Riegel writes:
>
> > On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
> >> On 08/22/2013 02:57 PM, Torvald Riegel wrote:
> >> > On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrot
This patch cleans up an implicit assumption about which TM methods
actually need to be run in serial mode. Instead, the transaction begin
code now asks a TM method's dispatch what it needs.
OK for trunk?
Torvald
commit 12170ba5013e855bf4ea784823961f63e3e2de4c
Author: Torvald Riegel
Date:
This patch clarifies the ABI requirements for data-logging functions in
libitm's documentation. Thanks to Luke Dalessandro for pointing this
out.
OK for trunk?
Torvald
commit b9cbb260f958f53afbea69675458f3f15a04b812
Author: Torvald Riegel
Date: Tue Oct 23 14:56:32 2012 +0200
Clarif
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 'std::u
unsafe 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
Date: Th
ce.
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
Date: Thu Jan 2
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 something to do with
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 wrote:
> >> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
> >>> On Jan 21, 2016, at 9:29 AM, Domi
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
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 thi
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,
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
of
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 h
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
>
and use non-sized dlete under the covers.)
2015-10-29 Torvald Riegel
* alloc_cpp.cc (_ZdlPvX, _ZdlPvXRKSt9nothrow_t, _ZGTtdlPvX,
_ZGTtdlPvXRKSt9nothrow_t, delsz_opnt): New.
* libitm.map: Add _ZGTtdlPvX and _ZGTtdlPvXRKSt9nothrow_t.
* libitm_i.h (gtm_alloc_action
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
> >
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_tS(S(_Znw,MA
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 sup
This patch supports the sized variants of operator delete.
Some change compare to v1.
Tested on x86_64-linux.
commit df00a283f2e37bd3c69f37783fa81dde7ccf1f94
Author: Torvald Riegel
Date: Thu Oct 29 18:52:20 2015 +0100
Support sized delete.
This adds transactional clones of the
ts?
commit 0a67dc5a13fd17a24fc667a251d000a73cd5159e
Author: Torvald Riegel
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/libitm/beginend.cc
@@ -13
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
> &g
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
re are also commented-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 R
ption): 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: To
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.
74c5fd924fe3e8d6bececce209d00bf0523bb4dc
Author: Torvald Riegel
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/libitm_i.h b/libitm/libitm_i.h
m test.
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
Date: Thu Nov 26 16:52:04 2015 +0100
libitm: Use multiplicative hashing in
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; /*
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. Doi
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
On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote:
> 2015-05-06 Gleb Fotengauer-Malinovskiy
>
> PR libitm/61164
> * local_atomic (__always_inline): Rename to...
> (__libitm_always_inline): ... this.
OK. Thanks.
and incomplete than what we had before. There
is no way we can precisely summarize the C++ memory model in the docs,
and there isn't really a need either.
OK for trunk?
2015-05-15 Torvald Riegel
* doc/extend.texi (__atomic Builtins): Use 'memory order' instead of
On Wed, 2015-04-29 at 23:23 -0400, Nuno Diegues wrote:
> Hello,
>
> I have taken the chance to improve the patch by addressing the
> comments above in this thread.
> Namely:
> - to use a simple random generator managed inside the library only
> - removed floating point usage and replaced by fix
On Mon, 2015-05-18 at 23:39 +0200, Andi Kleen wrote:
> > Are there better options for the utility function, or can we tune it to
>
> There is nothing better that isn't a lot slower.
Do you care to elaborate why? As-is, I find this statement to not be
convincing; at the very least we need to docu
On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote:
> Hello,
>
> On 15/05/15 17:22, Torvald Riegel wrote:
> > This patch improves the documentation of the built-ins for atomic
> > operations.
>
> The "memory model" to "memory order" change does
On Mon, 2015-05-18 at 23:27 -0400, Nuno Diegues wrote:
> On Mon, May 18, 2015 at 5:29 PM, Torvald Riegel wrote:
> >
> > Are there better options for the utility function, or can we tune it to
> > be less affected by varying txn length and likelihood of txnal vs.
> > n
On Thu, 2015-05-21 at 16:45 +0100, Matthew Wahab wrote:
> On 19/05/15 20:20, Torvald Riegel wrote:
> > On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote:
> >> Hello,
> >>
> >> On 15/05/15 17:22, Torvald Riegel wrote:
> >>> This patch improv
On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
> Hi,
>
> While writing atomic_word.h for the ARM backend to fix PR target/66200
> I
> thought it would make more sense to write it all up with atomic
> primitives instead of providing various fragile bits of inline
> asssembler. Th
On Fri, 2015-05-22 at 17:41 +0100, Matthew Wahab wrote:
> On 21/05/15 19:26, Torvald Riegel wrote:
> > On Thu, 2015-05-21 at 16:45 +0100, Matthew Wahab wrote:
> >> On 19/05/15 20:20, Torvald Riegel wrote:
> >>> On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote:
little in some cases, as well as reduce space required for futures
a little.
Comments?
commit 1543313a3b590e6422f5d547cabd6662e0a6f538
Author: Torvald Riegel
Date: Sun Nov 16 12:07:22 2014 +0100
[WIP] Optimize synchronization in std::future if futexes are available.
diff --git a/libstdc++-
There is an correctness issue related to mutex destruction. The added
documentation is a good start, but I'd still add some more for the
complicated pieces of reasoning. Details inline below.
On Tue, 2015-04-07 at 15:28 +0100, Jonathan Wakely wrote:
> diff --git a/libstdc++-v3/include/std/shared
On Tue, 2015-06-09 at 10:50 +0100, Ramana Radhakrishnan wrote:
>
> On 22/05/15 17:56, Torvald Riegel wrote:
> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
> >> Hi,
> >>
> >> While writing atomic_word.h for the ARM backend to fix PR ta
On Fri, 2015-06-12 at 10:30 +0100, Ramana Radhakrishnan wrote:
> On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely wrote:
> > On 11/06/15 23:56 +0200, Torvald Riegel wrote:
> >>>
> >>> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrot
-01-16 Torvald Riegel
* include/std/shared_mutex (shared_timed_mutex): Add POSIX-based
implementation.
commit e0a32ddb058d8b4dd563f89130d03bce220ace8c
Author: Torvald Riegel
Date: Thu Jan 15 22:29:23 2015 +0100
libstdc++: Add POSIX variant of shared_timed_mutex
ity to the synchronization code, but not a lot.
I'm happy to do this next week if people are interested in this.
Tested on x86_64-linux and the 30_threads/* tests.
OK for trunk?
commit 4b07d1c0ab807fd0fbedacde1e9fec99a7d75b6d
Author: Torvald Riegel
Date: Sun Nov 16 12:07:22 2014 +0100
libs
On Mon, 2015-02-09 at 09:10 -0800, Mike Stump wrote:
> On Feb 9, 2015, at 7:11 AM, Alex Velenko wrote:
> > The following patch makes atomic-op-consume.c XFAIL
> >
> > Is this patch ok?
>
> Ok.
>
> I’d shorten the comment above the xfail to be exceedingly short:
>
> /* PR59448 consume not imp
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
> * configure.ac: Add AC_CONFIG_FILES.
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 l
problematic load-via-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
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
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
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.)
Sor
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 not
On Fri, 2017-02-03 at 17:21 +0100, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 04:19:58PM +, Ramana Radhakrishnan wrote:
> > > > Would it be acceptable for those users to have loads that perform like
> > > > CAS loops, especially under contention? Or are these users more
> > > > concerned a
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 memory.
> >
> > Tested on
On Thu, 2016-09-15 at 09:22 +0200, Jakub Jelinek wrote:
> Hi!
>
> These days on many targets that use dl_iterate_phdr to find .eh_frame_hdr
> that way in most of the programs the old style EH registry is never used,
> yet we still lock a global mutex and unlock it soon afterwards to find out
> it
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 and atomics are available.
> > (a
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
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
> > &g
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 wro
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!
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/
ibitm support
and bugfixes on the compiler side).
Tested on x86_64-linux and x86-linux.
OK?
2016-01-07 Torvald Riegel
* include/bits/basic_string.h (basic_string): Declare friends.
* include/bits/c++config (_GLIBCXX_TXN_SAFE,
_GLIBCXX_TXN_SAFE_DYN, _GLIBCXX_USE_ALLOCATOR_NEW)
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
* beginend.cc (GTM::gtm_thread::serial_lock
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
* libitm_i.h (gtm_mask_stack): Remove
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
* beginend.cc (gtm_thread::trycommit): Fix
ssive optimizations of concurrent code.
Tested on x86_64-linux. Committed as r232353.
2016-01-13 Torvald Riegel
* beginend.cc (gtm_thread::trycommit): Fix seq_cst fences.
* config/linux/rwlock.cc (gtm_rwlock::write_lock_generic): Likewise.
(gtm_rwlock::write_unlock): Likewise.
c
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 vers
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 that
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.
>
Author: Torvald Riegel
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.
* libitm/testsuite/libitm.c/priv-1
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
Date: Sat Jan 16 23
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 depend
x86_64-linux, 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
Date: Sun Jan 17 19:21:13 2016 +0100
libstdc++: Fix usage of weak symbols i
On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote:
> On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel wrote:
> > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> >> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek wrote:
> >> > On Sat, Jan 16, 2
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 wrote:
> > > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> > >> On Sat, Jan 16,
64-linux.
Jon, okay from your side if Darwin testing succeeds?
commit 6987f84f278d2cbf5b828a8c81c1be84b292b1af
Author: Torvald Riegel
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/cow-stdexcept.c
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
On Tue, 2015-01-13 at 09:56 -0500, Andrew MacLeod wrote:
> The problem with the patch in the PR is the memory model is immediately
> promoted from consume to acquire. This happens *before* any of the
> memmodel checks are made. If a consume is illegally specified (such as
> in a compare_exch
On Tue, 2015-01-13 at 10:11 -0500, Andrew MacLeod wrote:
> On 01/13/2015 09:59 AM, Richard Biener wrote:
> > On Tue, Jan 13, 2015 at 3:56 PM, Andrew MacLeod wrote:
> >> Lengthy discussion : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
> >>
> >> Basically we can generate incorrect code for an
On Wed, 2015-01-14 at 10:44 -0500, Andrew MacLeod wrote:
> I think this brings us to where we ought to be... at least almost :-)
> The latest version I have is n3337, which still specifies that
> atomic_clear can't be memory_order_acquire or memory_order_acq_rel. Has
> that been updated to spe
if (!tx->trycommit ())
{
diff --git a/libitm/config/linux/rwlock.h b/libitm/config/linux/rwlock.h
index 987e580..f13d287 100644
--- a/libitm/config/linux/rwlock.h
+++ b/libitm/config/linux/rwlock.h
@@ -1,4 +1,4 @@
-/* Copyright (C) 2011 Free Software Foundation, Inc.
+/* Copyright (C) 201
On Wed, 2012-11-07 at 15:01 -0800, Richard Henderson wrote:
> I wrote the second of these patches first, and I'm uncertain about the
> desirability of the first of the patches.
>
> While working on the uninstrumented code path bulk patch, I noticed that
> nested transactions within the copy of the
On Wed, 2012-11-07 at 15:08 -0800, Andi Kleen wrote:
> Richard Henderson writes:
> >
> > Is it ever likely that we'd choose an uninstrumented path for a
> > nested transaction, given that we're already executing the instrumented
> > path for an outer transaction?
>
> I don't see why not. A small
On Thu, 2012-11-08 at 13:33 +0100, Torvald Riegel wrote:
> On Wed, 2012-11-07 at 15:01 -0800, Richard Henderson wrote:
> > I wrote the second of these patches first, and I'm uncertain about the
> > desirability of the first of the patches.
> >
> > While working
On Tue, 2012-11-06 at 08:11 -0800, Richard Henderson wrote:
> On 2012-11-05 17:09, Torvald Riegel wrote:
> > + if (likely(htm_fastpath && (prop & pr_hasNoAbort)))
>
> For reference, could the NoAbort clause be relaxed with an htm check
> in abortTransaction, and the
On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
> + // Honor an abort from abortTransaction.
> + else if (htm_abort_is_cancel(ret))
> + return a_abortTransaction | a_restoreLiveVariables;
The problem is that we cannot reliably detect whether an abort with a
ce
On Thu, 2012-11-08 at 20:34 -0800, Andi Kleen wrote:
> Richard Henderson writes:
> >
> > static inline void
> > -htm_abort ()
> > +htm_abort_retry ()
> > {
> >// ??? According to a yet unpublished ABI rule, 0xff is reserved and
> >// supposed to signal a busy lock. Source: andi.kl...@
On Fri, 2012-11-09 at 10:24 -0800, Andi Kleen wrote:
> Torvald Riegel writes:
>
> > On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
> >> + // Honor an abort from abortTransaction.
> >> + else if (htm_abort_is_cancel(ret))
> >>
On Fri, 2012-11-09 at 21:54 +0100, Andi Kleen wrote:
> > I'm not sure this is quite true. If a libitm-executed transaction is
>
> It's just a convention. You don't have to use it.
That's true ...
> Not doing it will
> just make abort profiling harder.
... but I disagree with this one. This wo
On Mon, 2014-09-29 at 16:53 +0400, Gleb Fotengauer-Malinovskiy wrote:
> -#undef __always_inline
> -#define __always_inline __attribute__((always_inline))
> +#define __libitm_always_inline inline __attribute__((always_inline))
The previous code seems to work in libstdc++. I believe that
eventuall
On Mon, 2014-09-29 at 17:38 +0200, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 05:35:24PM +0200, Torvald Riegel wrote:
> > On Mon, 2014-09-29 at 16:53 +0400, Gleb Fotengauer-Malinovskiy wrote:
> > > -#undef __always_inline
> > > -#define __always_inline _
ake any sense because other transactions can't
run anyway, and we should really just finish the serial-mode transaction
as fast as possible.
Peter and/or Andreas: Could you please check that this fixes the bug you
see on Power/s390? Thanks.
Torvald
commit 185af84e365e1bae31aea5afd6e67e81f3c
hy and will report back.
>
> Ok, we return outsideTransaction because the nesting level (tx->nesting)
> is zero.
That's a second bug in libitm, sorry. Can you try with the attached
patch additionally to the previous one? Thanks!
Torvald
commit 02dde6bb91107792fb0cb9f5c4785d
1 - 100 of 242 matches
Mail list logo
