Jan Kara writes:
> we've spotted the following mismatch between what kernel folks expect
> from a compiler and what GCC really does, resulting in memory corruption on
> some architectures. Consider the following structure:
> struct x {
> long a;
> unsigned int b1;
> unsigned int b2:
Snapshot gcc-4.5-20120202 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Feb 02, 2012 at 11:08:25AM -0800, Linus Torvalds wrote:
> On Thu, Feb 2, 2012 at 10:42 AM, Paul E. McKenney
> wrote:
> >>
> >> SMP-atomic or percpu atomic? Or both?
> >
> > Only SMP-atomic.
>
> And I assume that since the compiler does them, that would now make it
> impossible for us to g
On Thu, Feb 2, 2012 at 10:42 AM, Paul E. McKenney
wrote:
>>
>> SMP-atomic or percpu atomic? Or both?
>
> Only SMP-atomic.
And I assume that since the compiler does them, that would now make it
impossible for us to gather a list of all the 'lock' prefixes so that
we can undo them if it turns out t
On Wed, Feb 01, 2012 at 03:11:00PM -0800, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 2:45 PM, Paul E. McKenney
> wrote:
> >
> > My (perhaps forlorn and naive) hope is that C++11 memory_order_relaxed
> > will eventually allow ACCESS_ONCE() to be upgraded so that (for example)
> > access-once in
On Thu, Feb 2, 2012 at 8:28 AM, Michael Matz wrote:
>
> Sure. Simplest example: struct s {int i:24;} __attribute__((packed)).
>
> You must access only three bytes, no matter what. The basetype (int) is
> four bytes.
Ok, so here's a really *stupid* (but also really really simple) patch attached.
Hi,
On Thu, 2 Feb 2012, Aldy Hernandez wrote:
> > Seriously - is there any real argument *against* just using the base
> > type as a hint for access size?
>
> If I'm on the hook for attempting to fix this again, I'd also like to
> know if there are any arguments against using the base type.
S
Linus Torvalds writes:
> Seriously - is there any real argument *against* just using the base
> type as a hint for access size?
If I'm on the hook for attempting to fix this again, I'd also like to
know if there are any arguments against using the base type.
On 02/02/2012 02:51 PM, Paul Richard Thomas wrote:
> Many thanks for the patch. This makes for a rather complete
> implementation of OOP.
Excellent! It used to be said that the determined Real Programmer can
write Fortran programs in any language; now it seems that they can
write any language in
Hi,
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> But I also think that gcc is simply *buggy*, and has made them much
> nastier than they should be. What gcc *should* have done is to turn
> bitfield accesses into shift-and-masking of the underlying field as
> early as possible, and then do all o
On Thu, 2 Feb 2012, James Courtier-Dutton wrote:
> On 1 February 2012 15:19, Jan Kara wrote:
> > Hello,
> >
> > we've spotted the following mismatch between what kernel folks expect
> > from a compiler and what GCC really does, resulting in memory corruption on
> > some architectures. Consider
On Thu, 2 Feb 2012, David Sterba wrote:
> On Wed, Feb 01, 2012 at 04:19:18PM +0100, Jan Kara wrote:
> > We actually spotted this race in practice in btrfs on structure
> > fs/btrfs/ctree.h:struct btrfs_block_rsv where spinlock content got
> > corrupted due to update of following bitfield and there
* Linus Torvalds wrote:
> [...]
>
> And I realize that compiler people tend to think that loop
> hoisting etc is absolutely critical for performance, and some
> big hammer like "barrier()" makes a compiler person wince. You
> think it results in horrible code generation problems.
>
> It rea
On Wed, Feb 01, 2012 at 04:19:18PM +0100, Jan Kara wrote:
> We actually spotted this race in practice in btrfs on structure
> fs/btrfs/ctree.h:struct btrfs_block_rsv where spinlock content got
> corrupted due to update of following bitfield and there seem to be other
> places in kernel where this c
On 1 February 2012 15:19, Jan Kara wrote:
> Hello,
>
> we've spotted the following mismatch between what kernel folks expect
> from a compiler and what GCC really does, resulting in memory corruption on
> some architectures. Consider the following structure:
> struct x {
> long a;
> unsign
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> Rather than assertions, one could use predicates:
>
> #if #has_builtin(foo) && #has_attribute(bar)
> ...
> #endif
>
> The difference being that (1) predicates were designed specifically for
> this purpose, and (2) there’s no magic involved.
Hi,
Chris Lattner skribis:
> On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote:
>
>>>
>>> Interestingly enough:
>>> $ cat q.c
>>> __has_builtin
>>> $ clang -E q.c
>>>
>>
>> Yes, that’s what I was asking.
>>
>> It makes me think that the old CPP predicates (info "(gcc) Obsolete
>> Features")
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> IT IS A GCC BUG.
I think you are wrong when you assume that we think it is not a bug.
Repeating it repeatedly in all-caps doesn't make the fix appear
faster though.
Richard.
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> Just out of morbid curiosity, what happens if you have totally
> *separate* variables that just happen to link together? IOW, something
> like
>
>static struct { unsigned bit:1; } onebit;
>static volatile int var;
>
> and they just *happen* to
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 9:41 AM, Michael Matz wrote:
> >
> > One problem is that it's not a new problem, GCC emitted similar code since
> > about forever, and still they turned up only now (well, probably because
> > ia64 is dead, but sparc64 should have
On Mit, 2012-02-01 at 21:04 +, Boehm, Hans wrote:
[...]
> The C11 memory model potentially adds overhead in only two cases:
>
> 1. When current code involves touching a field that wouldn't otherwise
> be touched. There are odd cases in which this measurably slows down
> code, but I think all
21 matches
Mail list logo
