| 1 |
On 10/11/2014 07:57, "Paweł Hajdan, Jr." wrote: |
| 2 |
[snip] |
| 3 |
> I'd like to ask for every possible help with |
| 4 |
> <https://bugs.gentoo.org/show_bug.cgi?id=461954> blockers on amd64 and |
| 5 |
> x86. There are harder problems on arches like MIPS, but newer gcc is not |
| 6 |
> as urgent there I think. |
| 7 |
|
| 8 |
I've whittled down my MIPS problem (PR61538 // bug #516548) down to something |
| 9 |
screwy in the newer gcc-4.8 atomics for MIPS that appears to only affect |
| 10 |
R10000-based processors (so far). I am assuming it doesn't affect newer |
| 11 |
MIPS32/MIPS64 chips because someone would have caught that by now. It's got |
| 12 |
something to do with the new c++11 memory models. |
| 13 |
|
| 14 |
gcc-4.7 and earlier used __sync_lock_test_and_set() as a placeholder for |
| 15 |
atomic_exchange_acq(), which is an acquire memory op. That works fine. But in |
| 16 |
gcc-4.8, they added actual assembler for atomic_exchange_acq(), and that is |
| 17 |
somehow not playing nice with glibc's futex code on an R10000. Kernel-side, it |
| 18 |
gets stuck somewhere deep in freezable_schedule() and won't exit until you |
| 19 |
ctrl+c the stuck process. |
| 20 |
|
| 21 |
gcc upstream seems uninterested in addressing it right now, so I need to go |
| 22 |
poke libc-alpha next, I guess. Probably going to need a sharper stick. |
| 23 |
|
| 24 |
MIPS has no stable, so don't let it hold you guys back. Just keep gcc-4.7.x in |
| 25 |
the tree for a few more years. I've got time until glibc requires gcc-4.8 to |
| 26 |
get this bug figured out and fixed :) |
| 27 |
|
| 28 |
-- |
| 29 |
Joshua Kinard |
| 30 |
Gentoo/MIPS |
| 31 |
kumba@g.o |
| 32 |
4096R/D25D95E3 2011-03-28 |
| 33 |
|
| 34 |
"The past tempts us, the present confuses us, the future frightens us. And our |
| 35 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 36 |
|
| 37 |
--Emperor Turhan, Centauri Republic |
Archives