https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107958
--- Comment #10 from Ruslan Nikolaev ---
The latter example seems to work well for both gcc and clang. The behavior is
also consistent for both explicit and implicit constructors.
Thank you for clarifying that it was not a bug!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107958
--- Comment #9 from Ruslan Nikolaev ---
Interestingly, if I change the code a little bit and have a pair in the
constructor rather than two arguments, gcc seems to compile the code:
#include
#include
struct PairPtr {
PairPtr() {}
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
Suppose we have the following example with a class that has to keep two
pointers. (I actually encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91502
--- Comment #1 from Ruslan Nikolaev ---
btw, the same problem for
#include
int func(_Atomic(long) *a)
{
return (atomic_fetch_sub(a, 1) <= 0);
}
In the previous case clang/llvm was just like gcc, i.e., unable to optimize; in
this case
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
I have not specified the gcc version; it seems like it applies to any version.
I have noticed that if I write code:
#include
int func(_Atomic(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90606
Ruslan Nikolaev changed:
What|Removed |Added
CC||nruslan_devel at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524
--- Comment #5 from Ruslan Nikolaev ---
(In reply to Andrew Pinski from comment #4)
> Still is a binutils (assembler rather than the linker issue):
> .file "t.c"
> .text
> #APP
> a: .long func@plt - 4
> #NO_APP
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524
Ruslan Nikolaev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524
--- Comment #1 from Ruslan Nikolaev ---
btw, I have just compared the output with clang/llvm 7.0; the generated code
seems to be correct in both cases there.
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
Consider the following example for some -fpic -mcmodel=small compiled code.
There is an external function func() for which we store a relative reference
to the corresponding @plt stub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86693
--- Comment #3 from Ruslan Nikolaev ---
(In reply to Jakub Jelinek from comment #1)
> The reason why this works for sub/add is that x86 has xadd instruction, so
> we expand it as xadd and later on during combine find out we are actually
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86693
--- Comment #2 from Ruslan Nikolaev ---
Also may be (partially) related the following cases:
1.
#include
#include
void func2();
void func(_Atomic(unsigned long) * obj, void * obj2)
{
if (atomic_fetch_sub(obj, 1) == 1 && obj2)
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
(Compiled with O2 on x86-64)
Consider the following example:
void func1();
void func(unsigned long *counter)
{
if (__atomic_fetch_xor(counter, 1, __ATOMIC_ACQ_REL) == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791
--- Comment #3 from Ruslan Nikolaev ---
That is OK, I was talking about an extra 'cmp' instruction for the case when
the check is explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791
--- Comment #1 from Ruslan Nikolaev ---
Optimization flags -O2 in all cases
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
Just noticed that code is generated differently when using
__builtin_mul_overflow and an explicit check:
1. unsigned long long func(unsigned long long a, unsigned long long b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #18 from Ruslan Nikolaev ---
(In reply to andysem from comment #17)
> I'll clarify why I think load() should be allowed to issue writes on the
> memory. According to [atomics.types.operations]/18 in N4713,
> compare_exchange_*() is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
--- Comment #2 from Ruslan Nikolaev ---
Summary (from the mailing list):
Pros of the proposed approach:
1. Ability to use guaranteed lock-free double-width atomics (when mcx16 is
specified for x86-64, and always for arm64) in more or less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
--- Comment #1 from Ruslan Nikolaev ---
See also discussion in the gcc mailing list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70490
Ruslan Nikolaev changed:
What|Removed |Added
CC||nruslan_devel at yahoo dot com
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
I know, there are related issues already but decided to open a new issue
because it primarily relates to the interpretation of DR 459 by GCC and
response from C11/WG14.
(I
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
Partially related to the Bug 84431 (see description of the problem there) but
observed on ARM64 instead of x86/x86-64. (Not sure about ARM32.)
Test example:
__uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84431
--- Comment #6 from Ruslan Nikolaev ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Ruslan Nikolaev from comment #4)
> > Thanks! I was wondering if the patch also fixes the same thing for x86-64
> > (i.e., -m64); in which case we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #5 from Ruslan Nikolaev ---
After more t(In reply to Andrew Pinski from comment #1)
> IIRC this was done because there is no atomic load/stores or a way to do
> backwards compatible.
After more thinking about it... Should not it be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #4 from Ruslan Nikolaev ---
I guess, in this case you would have to fall-back to lock-based implementation
for everything. But does C11 even require that atomic_load work on read-only
memory?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #3 from Ruslan Nikolaev ---
(In reply to Ruslan Nikolaev from comment #2)
> Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
> that use 128-bit can simply use compare_and_exchange only (at least for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #2 from Ruslan Nikolaev ---
Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
that use 128-bit can simply use compare_and_exchange only (at least for
x86-64).
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
I looked up similar bugs, but I could not quite understand why it redirects to
libatomic when used with 128-bit cmpxchg in x86-64 even when '-mcx16' flag is
specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84431
--- Comment #4 from Ruslan Nikolaev ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 43471 [details]
> Prototype patch
>
> Prototype patch, compiles the testcase to:
>
> movl4(%esp), %eax
> movl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84431
--- Comment #2 from Ruslan Nikolaev ---
Sebastian, it is
gcc -m32 -Wall -O2 -S test.c
(the same is for clang)
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
In x86 and x86-64, the assumption is that upper bits of the CL register are
unused (i.e., masked) when doing a shift operation. It is not possible to do
shift for more
31 matches
Mail list logo
