http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #8 from Zhangxi Tan 2011-08-14
21:00:40 UTC ---
Thanks for the clear explanation.
I agree that a memory barrier would solve this issue.
Regarding the spinlock_unlock in linux, the regular arch_spin_unlock is
implemented with a single
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #4 from Zhangxi Tan 2011-08-14
01:30:33 UTC ---
I don't think this is an valid optimization.
There are only two memory models in SPARC32, TSO and PSO (not RMO in the 64-bit
v9). Both don't allow relaxing the read->write order, i.e.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #3 from Zhangxi Tan 2011-08-14
00:57:07 UTC ---
The code is equivalent to
volatile unsigned char lock;
int remap_barrier;
while (atomic_test_and_set(lock)) {
while (lock) {
;
}
}
remap_barrier++;
lock = 0;
Eric: could yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
Bug #: 50065
Summary: -Os, -O2, -O3 optimization breaks LD/ST ordering on
32-bit SPARC
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48781
--- Comment #2 from Zhangxi Tan 2011-04-26
22:25:42 UTC ---
(In reply to comment #1)
> The alignment of __uint128_t is 16byte. I think you are invoking undefined
> behavior by using a data type which increases the alignment.
_uint128_t does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48781
Summary: gcc generate movdqa instructions on unaligned memory
address when using -mtune=native -march=native
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
