ocation function
Product: gcc
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
--- 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
IRMED
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
gcc 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
void cv* wrongly allowed with -fno-rtti
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC
void cv* wrongly allowed with -fno-rtti
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC
--- 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
IRMED
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
IRMED
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
--- 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
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
st'.
--
Summary: GCC does 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
--- 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
tatus: UNCONFIRMED
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
ormal
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #4 from algrant at acm dot org ---
So using g++,
#include
int f1(std::atomic const *p, std::atomic const *q)
{
int flag = p->load(std::memory_order_consume);
return flag ? (q + flag - flag)->lo
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
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::atomic flag(0);
and calculate the address this way:
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 (i
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 (as in the
gcc dot gnu dot org
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
ned at gcc 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
29 matches
Mail list logo
