On Mon, Feb 24, 2014 at 3:35 PM, Linus Torvalds
wrote:
>
> Litmus test 1:
>
> p = atomic_read(pp, consume);
> if (p == &variable)
> return p->val;
>
>is *NOT* ordered
Btw, don't get me wrong. I don't _like_ it not being ordered, and I
actually did spend some time thinking abou
On Mon, Feb 24, 2014 at 03:35:04PM -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 2:37 PM, Paul E. McKenney
> wrote:
> >>
> >> What if the "nothing modifies 'p'" part looks like this:
> >>
> >> if (p != &myvariable)
> >> return;
> >>
> >> and now any sane compiler will happily
FX MOREL writes:
> Hi everyone,
>
> I am developing on a custom design using the LatticeMico32
> architecture and I use gcc 4.5.1 to compile C code for this arch.
>
> In this architecture, the loading of an address 0x always
> takes two assembly instructions to fetch the address because
>
Richard Sandiford writes
> >> AIUI the old form never really worked reliably due to things like
> >> newlib's setjmp not preserving the odd-numbered registers, so it
> >> doesn't seem worth keeping around. Also, the old form is identified
> >> by the GNU attribute (4, 4) so it'd be easy for the l
On Mon, Feb 24, 2014 at 2:37 PM, Paul E. McKenney
wrote:
>>
>> What if the "nothing modifies 'p'" part looks like this:
>>
>> if (p != &myvariable)
>> return;
>>
>> and now any sane compiler will happily optimize "q = *p" into "q =
>> myvariable", and we're all done - nothing invalid w
On Mon, Feb 24, 2014 at 11:54:46AM -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
> wrote:
> >
> > Good points. How about the following replacements?
> >
> > 3. Adding or subtracting an integer to/from a chained pointer
> > results in another chaine
On 02/24/2014 10:42 AM, Richard Sandiford wrote:
>...
>> AIUI the old form never really worked reliably due to things like
>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
>>> seem worth keeping around. Also, the old form is identified by the GNU
>>> attribute (4, 4) so
Hey all, I've just tried building Trunk from branches/google/main/ and
got the following failure in libsanitizer:
In file included from
/mnt/test/rvbd-root-gcc49/usr/include/features.h:356:0,
from /mnt/test/rvbd-root-gcc49/usr/include/arpa/inet.h:22,
from
../
Hi,
I am interested in contributing to the OpenMP project as part of GSoC 2014.
I am mailing to discuss ideas, to see if someone is willing to mentor
me and also if possible, to get a test patch in before the end of
application process so as to verify my qualification!
Looking forward to your f
On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
wrote:
>
> Good points. How about the following replacements?
>
> 3. Adding or subtracting an integer to/from a chained pointer
> results in another chained pointer in that same pointer chain.
> The results of addition and su
On Mon, Feb 24, 2014 at 10:14:01AM -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 9:21 AM, Paul E. McKenney
> wrote:
> >
> > 4. Bitwise operators ("&", "|", "^", and I suppose also "~")
> > applied to a chained pointer and an integer results in another
> > chained poin
Matthew Fortune writes:
> Richard Sandiford writes
>> I understand the need to deprecate the current -mgp32 -mfp64 behaviour.
>> I don't think we should deprecate -mfp64 itself though. Instead, why
>> not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for
>> modeless? So rather t
On Mon, Feb 24, 2014 at 9:21 AM, Paul E. McKenney
wrote:
>
> 4. Bitwise operators ("&", "|", "^", and I suppose also "~")
> applied to a chained pointer and an integer results in another
> chained pointer in that same pointer chain.
No. You cannot define it this way. Taking t
On Mon, Feb 24, 2014 at 09:38:46AM -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 co
On Mon, Feb 24, 2014 at 09:28:56AM -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;
>
On Mon, Feb 24, 2014 at 02:55:07PM +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 21 Feb 2014, Paul E. McKenney wrote:
>
> > > And with conservative I mean "everything is a source of a dependency, and
> > > hence can't be removed, reordered or otherwise fiddled with", and that
> > > includes code
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 load, then access to
> p->here->there->next->prev->stuff is supposed
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;
> > >
> > > atomic_XXX (p, CONSUME);
> > >
> > > orders against accesses '*p', '**p',
On Mon, Feb 24, 2014 at 07:57:24AM -0800, Linus Torvalds wrote:
> On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
> wrote:
> >
> > Let me think about it some more, but my gut feel is that just tweaking
> > the definition of what "ordered" means is sufficient.
> >
> > So to go back to the suggeste
Hi,
On Mon, 24 Feb 2014, Linus Torvalds wrote:
> > To me that reads like
> >
> > int i;
> > int *q = &i;
> > int **p = &q;
> >
> > atomic_XXX (p, CONSUME);
> >
> > orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
> > want to say that it orders against aliased storage
On Mon, Feb 24, 2014 at 8:37 AM, Linus Torvalds
wrote:
>
> So yes, the atomic_read() would be ordered wrt '*ptr' (getting 'q')
> _and_ '**ptr' (getting 'i'), but nothing else - including just the
> aliasing access of dereferencing 'i' directly.
Btw, what CPU architects and memory ordering guys te
On Mon, Feb 24, 2014 at 8:27 AM, Richard Biener
wrote:
>
> To me that reads like
>
> int i;
> int *q = &i;
> int **p = &q;
>
> atomic_XXX (p, CONSUME);
>
> orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
> want to say that it orders against aliased storage - but then
On Mon, Feb 24, 2014 at 4:57 PM, Linus Torvalds
wrote:
> On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
> wrote:
>>
>> Let me think about it some more, but my gut feel is that just tweaking
>> the definition of what "ordered" means is sufficient.
>>
>> So to go back to the suggested ordering ru
On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
wrote:
>
> Let me think about it some more, but my gut feel is that just tweaking
> the definition of what "ordered" means is sufficient.
>
> So to go back to the suggested ordering rules (ignoring the "restrict"
> part, which is just to clarify tha
Richard Sandiford writes
> Matthew Fortune writes:
> > All,
> >
> > Imagination Technologies would like to introduce the design of an O32
> > ABI extension for MIPS to allow it to be used in conjunction with MIPS
> > FPUs having 64-bit floating-point registers. This is a wide-reaching
> > design
I could see "storent" pattern in x86 machine descriptions (in sse.md)., but
internals doc don't mention it. Should we add a description about this in the
internals doc?
Regards
Ganesh
Hi,
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > And with conservative I mean "everything is a source of a dependency, and
> > hence can't be removed, reordered or otherwise fiddled with", and that
> > includes code sequences where no atomic objects are anywhere in sight [1].
> > In the lig
On 02/17/2014 06:50 PM, Roman Gareev wrote:
Hi Tobias,
thanks for the answer!
Hi Roman,
sorry for missing this mail.
I think that the segfault is being caused by NULL arguments being passedto
compute_deps
by loop_level_carries_dependences. *This is **causing **an* *assignment of**
28 matches
Mail list logo
