Memory outputs in inline asm

2014-02-26 Thread Andrew Haley
Say you have a pointer: int *p; and an inline asm that writes to a block of memory __asm__("\t0:\n" "\tstr wzr, [%2, #4]!\n" "\tsub %1, %1, #1\n" "\tcbnz %1, 0b\n" : "=m"(*p), "+r"(len) : "r"(p)); I presume this is wrong because *p only refers to p[0].

Re: Memory outputs in inline asm

2014-02-26 Thread Richard Biener
On Wed, Feb 26, 2014 at 11:32 AM, Andrew Haley wrote: > Say you have a pointer: > > int *p; > > and an inline asm that writes to a block of memory > > __asm__("\t0:\n" > "\tstr wzr, [%2, #4]!\n" > "\tsub %1, %1, #1\n" > "\tcbnz %1, 0b\n" > : "=m"(*p), "+r"

Re: [LM-32] Code generation for address loading

2014-02-26 Thread FX MOREL
On Tue, Feb 25, 2014 at 1:08 AM, Anthony Green wrote: > > Have you considered doing this through custom GNU linker relaxation > work? I would try this before hacking away at the compiler. > > AG > > This a very good idea indeed, I wasn't aware of this feature. I will give it a try based on othe

Re: Memory outputs in inline asm

2014-02-26 Thread Andrew Haley
On 02/26/2014 10:51 AM, Richard Biener wrote: > But yes, technically you write p[0] here but as "m" merely builds > an address to the memory I'd say that we have to treat any "m" > operand as possibly reading from / writing to / clobbering the > whole object that can be refered to using that addres

Re: Memory outputs in inline asm

2014-02-26 Thread Richard Biener
On Wed, Feb 26, 2014 at 12:10 PM, Andrew Haley wrote: > On 02/26/2014 10:51 AM, Richard Biener wrote: >> But yes, technically you write p[0] here but as "m" merely builds >> an address to the memory I'd say that we have to treat any "m" >> operand as possibly reading from / writing to / clobbering

Re: Memory outputs in inline asm

2014-02-26 Thread Andrew Haley
On 02/26/2014 12:24 PM, Richard Biener wrote: > An additional question that immediately pops up here is that > of TBAA - may we use the alias-set of the memory reference > to disambiguate other loads/stores against the asm? I would certainly hope so: I don't think the rule here should be any diffe

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Torvald Riegel
On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote: > On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Matz wrote: > > Hi, > > > > On Thu, 20 Feb 2014, Linus Torvalds wrote: > > > > > But I'm pretty sure that any compiler guy must *hate* that current odd > > > dependency-generation part,

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Torvald Riegel
On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote: > On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > > This needs to be as follows: > > > > [[carries_dependency]] int getzero(int i [[carries_dependency]]) > > { > > return i - i; > > } > > > > Otherwise dependencies won't get carried

Re: Memory outputs in inline asm

2014-02-26 Thread Michael Matz
Hi, On Wed, 26 Feb 2014, Richard Biener wrote: > > "\tstr wzr, [%2, #4]!\n" > > "\tsub %1, %1, #1\n" > > "\tcbnz %1, 0b\n" > > : "=m"(*p), "+r"(len) : "r"(p)); > > > > I presume this is wrong because *p only refers to p[0]. Is it > > possible to tell GCC t

Re: Memory outputs in inline asm

2014-02-26 Thread Richard Sandiford
Michael Matz writes: > On Wed, 26 Feb 2014, Richard Biener wrote: >> > "\tstr wzr, [%2, #4]!\n" >> > "\tsub %1, %1, #1\n" >> > "\tcbnz %1, 0b\n" >> > : "=m"(*p), "+r"(len) : "r"(p)); >> > >> > I presume this is wrong because *p only refers to p[0]. Is it >>

Re: Memory outputs in inline asm

2014-02-26 Thread Segher Boessenkool
FWIW: > __asm__("\t0:\n" > "\tstr wzr, [%2, #4]!\n" > "\tsub %1, %1, #1\n" > "\tcbnz %1, 0b\n" > : "=m"(*p), "+r"(len) : "r"(p)); "+r"(p) as well, you're modifying %2. Cheers, Segher

Re: Memory outputs in inline asm

2014-02-26 Thread Andrew Haley
On 02/26/2014 04:43 PM, Segher Boessenkool wrote: > "+r"(p) as well, you're modifying %2. Yes, yes, OK. :-) Andrew.

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Torvald Riegel
On Mon, 2014-02-24 at 09:38 -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 8:55 AM, Michael Matz wrote: > > > > So, let me try to poke holes into your definition or increase my > > understanding :) . You said "chain of pointers"(dereferences I assume), > > e.g. if p is result of consume l

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Torvald Riegel
On Mon, 2014-02-24 at 09:28 -0800, Paul E. McKenney wrote: > On Mon, Feb 24, 2014 at 05:55:50PM +0100, Michael Matz wrote: > > Hi, > > > > On Mon, 24 Feb 2014, Linus Torvalds wrote: > > > > > > To me that reads like > > > > > > > > int i; > > > > int *q = &i; > > > > int **p = &q; > > > > >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Paul E. McKenney
On Wed, Feb 26, 2014 at 02:04:30PM +0100, Torvald Riegel wrote: > xagsmtp2.20140226130517.3...@vmsdvma.vnet.ibm.com > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) > > On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote: > > On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Ma

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Joseph S. Myers
On Wed, 26 Feb 2014, Torvald Riegel wrote: > On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote: > > On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > > > > This needs to be as follows: > > > > > > [[carries_dependency]] int getzero(int i [[carries_dependency]]) > > > { > > > return i - i

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Torvald Riegel
On Wed, 2014-02-26 at 18:43 +, Joseph S. Myers wrote: > On Wed, 26 Feb 2014, Torvald Riegel wrote: > > > On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote: > > > On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > > > > > > This needs to be as follows: > > > > > > > > [[carries_dependenc

proposal to turn on some warnings by default

2014-02-26 Thread Mingjie Xing
Hello, I'm wondering if it's a good idea to turn on some warnings by default (or even promote them to error), such as -Wreturn-type on C. This would help programmers to avoid some mistakes. Regards, Mingjie