https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
--- Comment #8 from Carlos O'Donell <carlos at systemhalted dot org> --- On Sun, May 25, 2014 at 2:30 PM, John David Anglin <dave.ang...@bell.net> wrote: > 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. I consider this a defect in reload, but accept that a correct fix might be hard. > 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, Better is an adjective applied to a qlualifier. Better for what? Better for us because it's a faster fix? :-) > static inline int __attribute__((always_inline)) > __lll_mutex_lock(int *futex, int private) > { > register int *f asm ("r5") = futex; I'm fine with this as a workaround, but let's call it what it is, a workaround. > ... > > The other fix is to not inline __lll_mutex_lock. Then, one is sure that No, the locks should absolutely be inlined for performance reasons. > futex will be > in %r26 on entry, and it can be copied to another general register without > %r1 being > needed. In summary: - We need to change all hppa asms that might clobber %r1 to use fixed registers to avoid reload bugs. - In this particular case change the futex code to use another random register for the futex argument. Is that about right? Cheers, Carlos.
