http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #11 from algrant at acm dot org ---
Where do you get that this is racy if the access to data is not atomic? By
design, release/acquire and release/consume sequences don't require wholesale
changes to the way the data payload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #13 from algrant at acm dot org ---
I see what you mean - there is a race if threadB reads the data when the
flag is not set, i.e. in the case when the read value is never used.
Moving the read of data after the test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #6 from algrant at acm dot org ---
Here is a complete C++11 test case. The code generated for the two loads
in thread B doesn't maintain the required ordering:
...
ldrbw1, [x0]
uxtbw1, w1
adrp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #8 from algrant at acm dot org ---
I don't see how f can not be 0 or 1 here, but to make this even more clear
that there is no UB, define flag this way:
static std::atomicunsigned int flag(0);
and calculate the address this way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #4 from algrant at acm dot org ---
So using g++,
#include atomic
int f1(std::atomicint const *p, std::atomicint const *q)
{
int flag = p-load(std::memory_order_consume);
return flag ? (q + flag - flag)-load(std
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: algrant at acm dot org
int f2(int const *p, int const *q)
{
int flag = *p;
return flag ? *(q + flag - flag) : 0;
}
The evaluation *(q + flag - flag) is ordered after *p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #2 from algrant at acm dot org ---
Just realised that that last example is bogus, it should read:
inline int const *makedep(int const *a, ...) { return a; } // variadic
int f3(int const *p, int const *q) {
int flag = *p
--- Comment #2 from algrant at acm dot org 2009-03-18 09:45 ---
No, the enum is signed, see AAPCS 7.1.3: the container type is int
unless the upper bound is greater than 2147483647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39488
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC target triplet: arm-none-eabi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39488
not put 'const auto' structure on the stack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
--- Comment #6 from algrant at acm dot org 2009-03-06 14:44 ---
Right. The existence of a statically initialized object whose size can
be determined at compile-time to be larger than the (notional) type size,
is specific to GCC. Here's another thing: the assembler output shows
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
--- Comment #2 from algrant at acm dot org 2009-03-05 13:19 ---
No, the case is an extension to C. 6.5.3.4 was obviously written without
this case in mind. In this case the size... of its operand cannot be
determined from the type. Either sizeof doesn't return the (real) size
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39384
--- Comment #1 from algrant at acm dot org 2009-03-05 14:48 ---
Unwanted duplicate entry of 39383 caused by refreshing browser page.
*** This bug has been marked as a duplicate of 39383 ***
--
algrant at acm dot org changed:
What|Removed |Added
--- Comment #5 from algrant at acm dot org 2009-03-05 14:48 ---
*** Bug 39384 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38397
: algrant at acm dot org
GCC target triplet: ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
: algrant at acm dot org
GCC target triplet: ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37701
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 ---
*** Bug 37701 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 ---
*** This bug has been marked as a duplicate of 37697 ***
--
algrant at acm dot org changed:
What|Removed |Added
--- Comment #2 from algrant at acm dot org 2008-10-01 16:40 ---
Bug report in error.
--
algrant at acm dot org changed:
What|Removed |Added
Status
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685
--- Comment #1 from algrant at acm dot org 2008-07-01 10:21 ---
Similar argument applies to __attribute__((visibility(default))) .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685
--- Comment #2 from algrant at acm dot org 2006-05-02 07:20 ---
Actually, I now wonder if the g++ 4.1 behavior would be correct
by the proposed resolution of (still open) Core Language Issue 252.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27141
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27141
dot gnu dot org
ReportedBy: algrant at acm dot org
GCC build triplet: -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26841
dot gnu dot org
ReportedBy: algrant at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
29 matches
Mail list logo
