https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
--- Comment #7 from dave.anglin at bell dot net --- On 25-May-14, at 7:11 AM, aaro.koskinen at iki dot fi wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 > > --- Comment #6 from Aaro Koskinen <aaro.koskinen at iki dot fi> --- > Created attachment 32852 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32852&action=edit > Simplified reproducer. > > I tried to make a simpler reproducer. Thanks for simplifying the test case. The problem is now clear. > > $ hppa-linux-gnu-gcc pr60925.c -c -O2 -Wall -g -fPIC > pr60925.c: In function 'foo': > pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while > reloading > 'asm' > asm volatile( > ^ The problem is the argument "futex" used in the asm. When generating PIC code, register %r1 is needed for position independent loads and stores from memory. In the test, both statements involving __lll_mutex_lock are needed to trigger the error. Essentially, reload fails to handle the reloads needed for &lock because the asm clobbers %r1 and %r1 is needed for the reload. Possibly, reload should be able to do this because the reload insns should be emitted before %r1 is clobbered by the asm, but reload is complicated. A better fix is to ensure that the futex argument is placed in a general register that is not clobbered by the asm. This has to happen anyway. For example, static inline int __attribute__((always_inline)) __lll_mutex_lock(int *futex, int private) { register int *f asm ("r5") = futex; ... The other fix is to not inline __lll_mutex_lock. Then, one is sure that futex will be in %r26 on entry, and it can be copied to another general register without %r1 being needed. Dave -- John David Anglin dave.ang...@bell.net
