nt: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Target Milestone: ---
Consider the operation of mapping an int to the unique modular representative
in [0, 2^31).
Readable code:
#include
int mod31(int num) {
if (num < 0) {
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Target Milestone: ---
Consider these two simple versions of addition:
#include
std::atomic x;
int y;
void f(int a) {
x.store(x.load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66713
--- Comment #3 from Thomas Köppe ---
Note: The code in question, and the hand-written assembly, are taken from the
ZMQ library:
https://github.com/zeromq/libzmq/blob/master/src/atomic_ptr.hpp
I added the C++11 atomic support recenlty.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Target Milestone: ---
The code here: https://goo.gl/CiV4pl
compares a hand-written CAS with the C++11 atomic one. On Clang, the code comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
--- Comment #11 from Thomas Köppe ---
Created attachment 33240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33240&action=edit
Further fixing: Uses uintptr_ts for the difference
On Jonathan's suggestion I changed the distance computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
--- Comment #9 from Thomas Köppe ---
Argh, yes, I compiled the wrong file... indeed, the arena version works with
GCC 4.8.2 for me, too, and in Clang as well.
So... not an issue, I suppose?
The desired real application will be for containers al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
--- Comment #6 from Thomas Köppe ---
Created attachment 33236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33236&action=edit
Fixed demo that doesn't have UB on account of invalid pointer arithmetic
Here's a (very lazily) fixed version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
--- Comment #4 from Thomas Köppe ---
Ah, you're right, this offset pointer computation as it stands is undefined
behaviour. The intended use is to use those pointers only within a preallocated
arena, so that the pointers would indeed live in a co
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Created attachment 33231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33231&action=edit
Demonstrates bad code generation with -O3
I was writi
