https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
--- Comment #5 from Luke Geeson ---
Thank you for fixing this, Wilco! I will now test this bug using the code
emitted by Godbolt.
Consider again the same source program. When run through gcc with the same
flags we get the ARM assembly test:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
--- Comment #4 from Luke Geeson ---
Hi there,
Apologies here you go:
https://github.com/llvm/llvm-project/issues/65106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
--- Comment #2 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:0731889c026bfe8d55c4851422ca5ec9d037f7a0
commit r14-4365-g0731889c026bfe8d55c4851422ca5ec9d037f7a0
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
--- Comment #1 from Luke Geeson ---
Correction
We will follow up by reporting the bug for GCC.
->
We have reported this in LLVM as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
Bug ID: 111235
Summary: [Armv7-a]: Control-dependency between atomic accesses
removed by -O1.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104261
Richard Biener changed:
What|Removed |Added
Target|i?86|i?86-*-*
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104261
Andrew Pinski changed:
What|Removed |Added
Target||i?86
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104261
Bug ID: 104261
Summary: gcc uses fildq and fistpq on unaligned addesss for
atomic accesses
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906
Bug #: 54906
Summary: write introduction incorrect wrt the C++11 memory
model (case with atomic accesses)
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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.html
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.
You
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 documented
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 every target.
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 fairly sure
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 instead.
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 as
* 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
instruction
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 scalar
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
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 object in memory
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 doubt we
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
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
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 already have
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).
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 to assume that
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
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 == 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, will be
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
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
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 carefully enough
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 effects
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
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 machine
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
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
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
46 matches
Mail list logo
