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