On 3/5/08, Andrew Haley <[EMAIL PROTECTED]> wrote:
> The proposed memory model partly described at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.ht
Segher Boessenkool <[EMAIL PROTECTED]> writes on Tue, 04 Mar
2008 01:25:33 +0100
> The Linux kernel, and probably some user-space applications and
> libraries
> as well, depend on GCC guaranteeing (a variant of) the following:
>
> "any access to a naturally aligned sca
* Segher Boessenkool:
> Good point. Suggestions for better wording? How does
>
> "any access to a naturally aligned scalar object in memory
> that is not a bit-field and fits in a general purpose integer
> machine register, will be performed by a single machine
> instruct
On Wed, Mar 05, 2008 at 06:05:44PM +, Andrew Haley wrote:
> > Hm, just out of curiosity, does not Java require 32-bit stores to be
> > atomic?
>
> Yes.
Linux uses typedef int sig_atomic_t; for all architectures, so if ARM
stores an int as two 16-bit guantities, it breaks ISO C requirements
Martin Jambor wrote:
> On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
>>> AFAIK the only reason we don't break this rule is that doing so would
>>> be grossly inefficient; there's nothing to stop any gcc back-end with
>>> (say) seriously slow DImode writes from using two SImode writes
On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
> > AFAIK the only reason we don't break this rule is that doing so would
> > be grossly inefficient; there's nothing to stop any gcc back-end with
> > (say) seriously slow DImode writes from using two SImode writes instead.
>
> I'm fairl
> "kai-gcc" == kai-gcc <[EMAIL PROTECTED]> writes:
kai-gcc> A. There's something similar in the C standard: see
kai-gcc> sig_atomic_t. It might be possible to steal some wording
kai-gcc> from there.
kai-gcc> B. This guarantee - at least as I describe it below - cannot
kai-gcc> work for
On Tue, Mar 04, 2008 at 04:41:16PM -0500, Paul Koning wrote:
> > "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
> Segher> I disagree. People are relying on this undocumented GCC
> Segher> behaviour already, and when things break, chaos ensues. If
> Segher> we change this to be
Ross Ridge wrote:
> Segher Boessenkool writes:
>> ... People are relying on this undocumented GCC behaviour already,
>> and when things break, chaos ensues.
>
> GCC has introduced many changes over the years that have broken many
> programs that have relied on undocumented or unspecified behaviour
Segher Boessenkool writes:
>... People are relying on this undocumented GCC behaviour already,
>and when things break, chaos ensues.
GCC has introduced many changes over the years that have broken many
programs that have relied on undocumented or unspecified behaviour.
You won't find much sympathy
> AFAIK the only reason we don't break this rule is that doing so would
> be grossly inefficient; there's nothing to stop any gcc back-end with
> (say) seriously slow DImode writes from using two SImode writes instead.
I'm fairly sure ARM already breaks this "rule".
Currently it probably only eff
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
>> As I said before, I think any words of this form SHOULD NOT be
>> added. All it does is add words to the documentation that provide
>> NO guarantee of anything -- but in a way that will confuse those
>> who don't read it care
Segher Boessenkool wrote:
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort of guarantee.
The idea is
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
Segher> Good point. Suggestions for better wording? How does
Segher> "any access to a naturally aligned scalar object in memory
Segher> that is not a bit-field and fits in a general purpose integer
Segher> machine register, wi
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
Richard Guenther wrote:
On Tue, Mar 4, 2008 at 7:31 PM, David Daney <[EMAIL PROTECTED]> wrote:
Perhaps anything declared volatile should have these semantics.
Although mentioning 'volatile' on the lkml is probably not a good idea.
Certainly not. volatile has nothing to do with atomic acce
On Tue, Mar 4, 2008 at 7:31 PM, David Daney <[EMAIL PROTECTED]> wrote:
> Jakub Jelinek wrote:
> > On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
> >>> Typically those would be found in asm statements.
> >>> I suspect it would be valuable to have standardized primitives for
> >>>
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>> We don't have atomic read or atomic write builtins (ok, you could
>> abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop with
>> __sync_compare_and_swap_val for atomic store, but that's a
>> horrible overkill. Being able
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
> >Typically those would be found in asm statements.
>
> >I suspect it would be valuable to have standardized primitives for
> >atomic actions (semaphores, spinlocks, test-and-set primitives,
> >circular buffers, pick one).
>
> We alre
Paul Koning wrote:
I'm really wondering why this is being considered.
A documented property of the form "GCC will use a single instruction
to do X when possible" means exactly nothing. In particular, to call
such a statement a "guarantee" is seriously misleading.
I agree.
If Linux needs the
I'm really wondering why this is being considered.
A documented property of the form "GCC will use a single instruction
to do X when possible" means exactly nothing. In particular, to call
such a statement a "guarantee" is seriously misleading.
If Linux needs the single-instruction property for
> Well if they do require more than one instruction, the rule has
> no effect ("whenever possible"). If they can be done in one
> instruction (as on the x86), then why not require this, why
> make a special case?
We don't even guarantee consistent behavior for volatile bitfields, so I
really dou
On Mon, Mar 03, 2008 at 11:08:24PM -0500, Robert Dewar wrote:
> Segher Boessenkool wrote:
> >>>The Linux kernel, and probably some user-space applications and
> >>>libraries
> >>>as well, depend on GCC guaranteeing (a variant of) the following:
> >>> "any access to a naturally aligned scalar obj
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single m
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single m
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single
This seems somewhat like other issues we have dealt with concerning
thread safety. Perhaps an entire section addressing code generation
issues related to correct multi-threaded semantics.
I like that idea. But, we need to decide what those correct semantics
_are_.
Or we can wait for that to
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
34 matches
Mail list logo
