Re: gcc generated long read out of bounds segfault

2014-02-22 Thread Eric Botcazou
> Before I file a bug report I wanted to check to see if my expectations > are wrong or if this is a compiler bug. Is there anything that allows > the compiler to generate instructions that would read beyond the end > of an array potentially causing a crash if the page isn't accessible? It's PR m

Re: gcc generated long read out of bounds segfault

2014-02-22 Thread David Fries
On Sat, Feb 22, 2014 at 08:49:38AM +0100, Andreas Schwab wrote: > David Fries writes: > > > The attached program sets up and reads through the array with extra > > padding at the of the array from 8 bytes to 0 bytes. Padding from 4 > > to 0 crashes. > > This program has undefined behaviour beca

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

2014-02-22 Thread Torvald Riegel
On Thu, 2014-02-20 at 10:18 -0800, Paul E. McKenney wrote: > On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140220172700.0...@vmsdvm4.vnet.ibm.com > > X-Xagent-Gateway: vmsdvm4.vnet.ibm.com (XAGSMTP2 at VMSDVM4) > > > > On Wed, 2014-02-19 at 20:01 -0800, Paul E. McK

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

2014-02-22 Thread Torvald Riegel
On Thu, 2014-02-20 at 11:09 -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel wrote: > > On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote: > >> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney > >> wrote: > >> > > >> > You really need that "consume" to be "a

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

2014-02-22 Thread Paul E. McKenney
On Sat, Feb 22, 2014 at 07:30:37PM +0100, Torvald Riegel wrote: > xagsmtp2.20140222183231.5...@emeavsc.vnet.ibm.com > X-Xagent-Gateway: emeavsc.vnet.ibm.com (XAGSMTP2 at EMEAVSC) > > On Thu, 2014-02-20 at 10:18 -0800, Paul E. McKenney wrote: > > On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Ri

Re: gcc generated long read out of bounds segfault

2014-02-22 Thread Andreas Schwab
David Fries writes: > The structure is only made up of an 8 bit type "char", and it is > aligned to a multiple of the struct rgb data size which is 3. How is > that unaligned? Sorry, I've miscomputed the alignment. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA

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

2014-02-22 Thread Linus Torvalds
On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel wrote: > > Stating that (1) "the standard is wrong" and (2) that you think that > mo_consume semantics are not good is two different things. I do agree. They are two independent things. I think the standard is wrong, because it's overly complex, h

gcc-4.7-20140222 is now available

2014-02-22 Thread gccadmin
Snapshot gcc-4.7-20140222 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140222/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

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

2014-02-22 Thread Paul E. McKenney
On Sat, Feb 22, 2014 at 01:53:30PM -0800, Linus Torvalds wrote: > On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel wrote: > > > > Stating that (1) "the standard is wrong" and (2) that you think that > > mo_consume semantics are not good is two different things. > > I do agree. They are two indepe

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

2014-02-22 Thread Linus Torvalds
On Sat, Feb 22, 2014 at 4:39 PM, Paul E. McKenney wrote: > > Agreed, by far the most frequent use is "->" to dereference and assignment > to store into a local variable. The other operations where the kernel > expects ordering to be maintained are: > > o Bitwise "&" to strip off low-order b