[Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'

["dave.anglin at bell dot net" <gcc-bugzilla@gcc.gnu.org>]

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.anglin@bell.net