On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
> On 17/07/15 13:26, Jakub Jelinek wrote:
> > On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses curren
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 in
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
(specialized)
On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote:
> > I'd like to know, based on the GCC experience, how important we consider
> > optimizations that may turn data dependencies of pointers into control
> > d
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 wrote:
> > > I'd like to know, based on the GCC experience, how important we consider
> > >
On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote:
> On Thu, Feb 25, 2016 at 6:33 PM, 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 wrote:
> >> > I'd like to kno
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 wrote:
> > > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> > >> On Tue, Feb 23, 2
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 cond
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
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.
>
> The gccgo library
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 store
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.
&
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, doing
&g
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 this ABI specification s
On Tue, 2014-04-29 at 09:11 -0400, Leo Ferres wrote:
> Hello,
>
> Suppose the following C code.
>
> int t = __sync_fetch_and_add(&s->r, 1);
>
> s is a struct with member r, which is an volatile int.
>
> Is this an atomic operation, even if you include the indirection?
The atomic operation is o
On Fri, 2014-12-26 at 23:19 +, Andrew Haley wrote:
> On 26/12/14 22:49, Matt Godbolt wrote:
> > At the moment I think the best I can do is to use an inline assembly
> > version of the increment which prevents GCC from doing any
> > optimisation upon it. That seems rather ugly though, and if any
On Fri, 2014-12-26 at 22:26 +, Andrew Haley wrote:
> On 26/12/14 20:32, Matt Godbolt wrote:
>
> > I'm investigating ways to have single-threaded writers write to memory
> > areas which are then (very infrequently) read from another thread for
> > monitoring purposes. Things like "number of uni
This adds a POSIX-based implementation of shared_timed_mutex, using
pthread_rwlock_* operations directly instead of implementing with
mutexes and two condvars. This enables using an optimized
pthread_rwlock_t on POSIX.
Tested on x86_64-linux.
OK?
2015-01-16 Torvald Riegel
* include
On Tue, 2015-05-19 at 17:55 -0700, Paul E. McKenney wrote:
> http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
I have been discussing Section 7.9 with Paul during last week.
While I think that 7.9 helps narrow down the problem somewhat, I'm still
concerned that it effectively
On Thu, 2015-05-21 at 13:42 -0700, Linus Torvalds wrote:
> On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
> wrote:
> >
> > The compiler can (and does) speculate non-atomic non-volatile writes
> > in some cases, but I do not believe that it is permitted to speculate
> > either volatile or atomic
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 officia
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
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 16-byt
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 contention
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
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
> > t
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 h
On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
> Torvald Riegel writes:
> > 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 th
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 writes:
> > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
> > >> (1) Does the approach seem reasonable?
&g
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 in
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 taken,
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
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 -O
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. Please
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 opera
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
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 looks
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 respons
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
> > final
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
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
> wrote:
>
> > ... does not imply this latter statement. The statement you cited
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
> cmpxc
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 t
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 there
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
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 how
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 RMW
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
> > good solution exists
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 tra
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 a
On Mon, 2011-09-12 at 08:51 -0500, Aldy Hernandez wrote:
> Jakub Jelinek writes:
>
> > In particular, is transactional-memory branch mergeable within
> > a month and half, at least some parts of cxx-mem-model branch,
> > bitfield lowering? What is the status of lra, reload-2a, pph,
>
> Torvald
On Thu, 2011-10-20 at 14:27 +0200, Duncan Sands wrote:
> And that's it. The price you pay for this simplicity is the need to keep
> track
> of uses - and this does cost compilation time (clear to anyone who does some
> profiling of LLVM) but it isn't that big. The big advantage is that memory
>
Hello everyone,
we thought to take this conversation to the list because it is related
to the GCC implementation of Cilk+. My questions to Balaji are quoted,
Balaji's replies are marked with BVI>.
On Fri, 2011-09-23 at 10:42 -0700, Iyer, Balaji V wrote:
> > 1) Implicit syncs are said to be called
On Tue, 2011-11-01 at 10:49 +0100, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> > This is somewhat of a me-too message for the transactional-memory work. We
> > would also like it to be considered for merging with mainline before the end
> > of stage1.
[sni
On Thu, 2011-11-03 at 16:50 -0400, Jack Howarth wrote:
> I am trying to test the proposed merge of the transactional memory branch on
> x86_64-apple-darwin11. Since the posted patches on gcc-patches seem to have
> malformed sections, I used the merge patches from
> http://quesejoda.com/redhat/tm-
On Thu, 2011-11-10 at 14:22 +0100, Rainer Orth wrote:
> I think that at least some of the gaps need to be filled, notably libgcc
> (recently bugs have been filed under other), libitm (new with the
> trans-mem merge, but fits nowhere else)
Something for libitm would probably make sense (or "trans-m
We are aware that the TM language constructs should be documented in
extend.texi. However, the most recent public version of the C++ TM
specification document is outdated, and a new version is supposed to be
released in a few weeks.
Therefore, we'd like to wait until the release of the new specif
On Thu, 2011-11-17 at 17:22 +0100, Andi Kleen wrote:
> On Thu, Nov 17, 2011 at 03:14:57PM +0100, Torvald Riegel wrote:
> > We are aware that the TM language constructs should be documented in
> > extend.texi. However, the most recent public version of the C++ TM
> > spec
On Thu, 2011-12-15 at 10:51 -0500, Patrick Marlier wrote:
> Here a list of known bugs for trans-mem. I have tried to sort it by
> priority (highest first).
Thanks for this list!
Items that I would add:
* Publication safety could potentially be violated. We suspect this can
happen when loads ar
stage3 is over, so let's have a look at the open bugs again...
Looking at Patrick's old list, the following bugs are still open
> [trans-mem] save/restore of thread-local data in nested txns is missing
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581
Aldy, you wanted to take a look. W
On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote:
> On my side, I was able to fix the problem with genome but the patch is
> not clean at all and I need to find exactly where and why the problem
> was fixed.
What do you mean? Do you still see issues with Genome, even with the
returns-tw
On Tue, 2012-01-10 at 17:29 -0500, Patrick Marlier wrote:
> On 01/09/2012 04:19 PM, Patrick Marlier wrote:
> > On 01/09/2012 04:04 PM, Torvald Riegel wrote:
> >> On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote:
> >>> On my side, I was able to fix the proble
On Wed, 2012-02-01 at 16:19 +0100, Jan Kara wrote:
> I've raised the issue with our GCC guys and they said to me that: "C does
> not provide such guarantee, nor can you reliably lock different
> structure fields with different locks if they share naturally aligned
> word-size memory regions. The C
On Wed, 2012-02-01 at 08:41 -0800, Linus Torvalds wrote:
> If the gcc people aren't willing to agree that this is actually a flaw
> in the standard (one that is being addressed, no less)
It has been addressed in the standards.
> and try to fix
> it,
Again, this is being worked on, see http://gcc
On Wed, 2012-02-01 at 11:47 -0800, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 9:42 AM, Torvald Riegel wrote:
> >
> > We need a proper memory model.
>
> Not really.
>
> The fact is, the kernel will happily take the memory model of the
> underlying hardware.
You
On Wed, 2012-02-01 at 09:29 -0800, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 9:08 AM, Torvald Riegel wrote:
> >
> > What do the kernel folks think about the C11 memory model? If you can
> > spot any issues in there, the GCC community would certainly like to
> > kn
On Wed, 2012-02-01 at 12:59 -0800, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 12:41 PM, Torvald Riegel wrote:
> >
> > You do rely on the compiler to do common transformations I suppose:
> > hoist loads out of loops, CSE, etc. How do you expect the compiler to
>
On Wed, 2012-02-01 at 13:20 -0800, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 12:53 PM, Torvald Riegel wrote:
> >
> > For volatile, I agree.
> >
> > However, the original btrfs example was *without* a volatile, and that's
> > why I raised the memory mode
On Fri, 2012-02-03 at 12:00 -0800, Linus Torvalds wrote:
> Of course, it you expose some intrinsic for the whole "ll/sc" model
> (and you then turn it into cmpxchg on demand), we could literally
> open-code it.
>
> That is likely the most *flexible* approach for a compiler. I think
> pretty much e
On Mon, 2013-05-06 at 16:17 +0400, Evgeny Gavrin wrote:
> What do you think about support of OpenACC 1.0
> (http://www.openacc-standard.org/) in gcc?
Is there a specific reason for targeting 1.0 instead of 2.0 (besides 2.0
still being declared as a draft)?
Also, adding to Tobias' question: Which
On Tue, 2013-05-07 at 13:00 +0400, Evgeny Gavrin wrote:
> Hi, all!
>
> > Which accelerators do you intent to handle? "Accelerator" is a rather
> > broad term, covering DSPs, GPUs, Intel's MIC, ...
> The idea is to emit OpenCL from high-GIMPLE, for know. So, any device
> that has OpenCL support
On Tue, 2013-05-07 at 17:34 +0200, Jakub Jelinek wrote:
> On Tue, May 07, 2013 at 11:02:08AM +0200, Tobias Burnus wrote:
> > Richard Biener wrote:
> > >We're going to look at supporting HSA from GCC (which would make
> > >it more or less trivial to also target openCL I think)
> >
> > For the frien
On Tue, 2013-05-07 at 10:27 +0200, Richard Biener wrote:
> On Mon, May 6, 2013 at 5:16 PM, Jeff Law wrote:
> > On 05/06/2013 07:41 AM, Tobias Burnus wrote:
> >>
> >> Evgeny Gavrin wrote:
> >>>
> >>> What do you think about support of OpenACC 1.0
> >>> (http://www.openacc-standard.org/) in gcc?
> >
On Tue, 2013-05-07 at 12:46 +0200, Richard Biener wrote:
> On Tue, May 7, 2013 at 12:42 PM, Richard Biener
> wrote:
> > On Tue, May 7, 2013 at 11:02 AM, Tobias Burnus wrote:
> >> Richard Biener wrote:
> >>>
> >>> We're going to look at supporting HSA from GCC (which would make it more
> >>> or le
On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote:
> Hi,
>
> I'm currently implementing support for hardware transactional memory
> in the S/390 backend and ran into a problem with saving and restoring
> the floating point registers.
>
> On S/390 the tbegin instruction starts a transaction
On Wed, 2013-05-22 at 11:03 +0200, Andreas Krebbel wrote:
> On 21/05/13 16:28, Torvald Riegel wrote:
> > On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote:
> > You could also start with supporting s390 HTM through the transactional
> > language construc
On Wed, 2013-05-29 at 10:06 -0400, Ryan Johnson wrote:
> On 29/05/2013 9:41 AM, Ian Lance Taylor wrote:
> > On Tue, May 28, 2013 at 9:02 PM, Ryan Johnson
> > wrote:
> >> Maybe I misunderstood... there's currently a (very small) cache
> >> (unwind-dw2-fde-dip.c) that lives behind the loader mutex.
On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote:
> On 05/28/2013 08:09 PM, Václav Zeman wrote:
>
> > If the bottleneck is really in glibc, then you should probably ask them
> > to fix it. Could the mutex be changed rwlock instead?
>
> rwlocks don't eliminate hardware contention, so I doub
On Thu, 2013-05-30 at 11:28 +0200, Jakub Jelinek wrote:
> On Thu, May 30, 2013 at 11:21:08AM +0200, Torvald Riegel wrote:
> > On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote:
> > > On 05/28/2013 08:09 PM, Václav Zeman wrote:
> > >
> > > > If the
On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote:
> I'm currently implementing support for hardware transactional memory in
> the rs6000 backend for POWER8. Things seem to be mostly working, but I
> have run into a few issues I'm wondering whether other people are seeing.
>
> For me, all of
, 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 185af84e365e1bae31aea5afd6e67e81f3c32c72
Author: Torvald Riegel
Date: Wed Jun 19 16:42:24 2013
We will have a BOF on accelerators at GNU Tools Cauldron: Sunday July
14, 11:30am. Below is an abstract. If you have any comments in
advance, for example further suggestions about what to discuss at his
BOF or at Cauldron, please let me know.
In this BOF, we will discuss how we can support acce
The Accelerator BOF at the GNU Tools Cauldron was worthwhile. Several
people presented their current work or announced upcoming projects in
the accelerator space. There was significant interest from the Cauldron
attendees; we had about 40 People in the room on the first day, and
about 20 in the f
On Mon, 2013-08-05 at 15:03 +0100, Richard Sandiford wrote:
> Sorry for the long mail and for what's probably an FAQ. I did try to find
> an answer without bothering the list... (and showing my ignorance so much :-))
>
> At the moment, the s390 backend treats all atomic loads as simple loads
> an
On Wed, 2013-08-28 at 13:06 +0200, Jakub Jelinek wrote:
> On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote:
> > >From the accelerator BOF video I gather we agreed on using the GOMP
> > representation as unified middle-end. What I didn't get is whether we
> > agreed on libgomp being t
On Wed, 2013-08-28 at 13:21 +0200, Richard Biener wrote:
> On Wed, Aug 28, 2013 at 1:06 PM, Jakub Jelinek wrote:
> > On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote:
> >> >From the accelerator BOF video I gather we agreed on using the GOMP
> >> representation as unified middle-end.
On Mon, 2013-09-09 at 15:37 +0200, Tobias Burnus wrote:
> Dear all,
>
> sometimes it can be useful to annotate loops for better vectorization,
> which is rather independent from parallelization.
>
> For vectorization, GCC has [0]:
> a) Cilk Plus's #pragma simd [1]
> b) OpenMP 4.0's #pragma omp
On Mon, 2013-09-09 at 10:18 -0400, Tim Prince wrote:
> Current Intel implementations of safelen will fail to vectorize and give
> notice if the value is set unnecessarily large. It's been agreed that
> increasing the safelen value beyond the optimum level should not turn
> off vectorization.
Y
On Mon, 2013-11-04 at 17:28 +1300, Maxim Kuvyrkov wrote:
> I am considering a project to add Apple's blocks [*] extension to GCC. I am
> looking at adding blocks support to C, C++ and Obj-C/C++ front-ends.
>
> There are many challenges (both technical and copyright) that require work
> before a
On Mon, 2013-11-04 at 16:39 +, Joseph S. Myers wrote:
> On Mon, 4 Nov 2013, Torvald Riegel wrote:
>
> > What is the status of this or similar features (eg, lambdas) in ISO C?
> > IOW, what was the feedback on the blocks part of
> > http://www.open-std.org/jtc1/sc22
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > On 02/06/14 18:25, David Howells wrote:
> > >
> > > Is it worth considering a move towards using C11 atomics and barriers and
> > > compiler intrinsics inside the kernel
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > > On 02/06/14 18:25, David Howells wrote:
> > > >
> > > > Is it worth considering a move towards us
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> > > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > >
On Thu, 2014-02-06 at 22:13 +, Joseph S. Myers wrote:
> On Thu, 6 Feb 2014, Torvald Riegel wrote:
>
> > > It seems that nobody really
> > > agrees on exactly how the C11 atomics map to real architectural
> > > instructions on anything but the trivial architec
On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> > > > There
On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > > &g
On Fri, 2014-02-07 at 18:06 +0100, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb 0
On Fri, 2014-02-07 at 08:50 -0800, Paul E. McKenney wrote:
> On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > Hopefully some discussion of out-of-thin-air values as well.
> >
> > Yes, absolutely shoot store
On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote:
> On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
> > > &g
e(r)
> proof that out-of-thin-air values cannot be observed in the face of any
> compiler optimization that refrains from reordering a prior relaxed load
> with a subsequent relaxed store.
>
> > Stores can, of course, be observed out-of-order but that's a
1 - 100 of 183 matches
Mail list logo
