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

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

[aaro.koskinen at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

            Bug ID: 60925
           Summary: [4.9 Regression] hppa: can't find a register in class
                    'R1_REGS' while reloading 'asm'
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aaro.koskinen at iki dot fi

Build failure when compiling GLIBC 2.19 with GCC 4.9.0 on PA-RISC:

hppa-linux-gnu-gcc gethstbyad.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g
-Wstrict-prototypes   -fPIC -fexceptions      -I../include
-I/home/aaro/los/work/parisc/glibc-2.19-build/default/inet 
-I/home/aaro/los/work/parisc/glibc-2.19-build/default 
-I../ports/sysdeps/unix/sysv/linux/hppa/nptl 
-I../ports/sysdeps/unix/sysv/linux/hppa  -I../nptl/sysdeps/unix/sysv/linux 
-I../nptl/sysdeps/pthread  -I../sysdeps/pthread 
-I../ports/sysdeps/unix/sysv/linux  -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv 
-I../ports/sysdeps/unix/sysv  -I../sysdeps/unix/sysv  -I../nptl/sysdeps/unix 
-I../ports/sysdeps/unix  -I../sysdeps/unix  -I../sysdeps/posix 
-I../ports/sysdeps/hppa/hppa1.1  -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64 
-I../ports/sysdeps/hppa/fpu  -I../ports/sysdeps/hppa/nptl 
-I../ports/sysdeps/hppa  -I../sysdeps/ieee754  -I../sysdeps/generic  -I../nptl 
-I../ports  -I.. -I../libio -I. -nostdinc -isystem
/home/aaro/los/work/parisc/toolchain/lib/gcc/hppa-linux-gnu/4.9.0/include
-isystem
/home/aaro/los/work/parisc/toolchain/lib/gcc/hppa-linux-gnu/4.9.0/include-fixed
-isystem /home/aaro/los/work/parisc/toolchain/glibc/hppa-linux-gnu/usr/include 
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
/home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os -MD -MP
-MF /home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os.dt
-MT /home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os
In file included from ../include/atomic.h:50:0,
                 from
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:25,
                 from ../nptl/descr.h:30,
                 from ../ports/sysdeps/hppa/nptl/tls.h:56,
                 from ../include/link.h:44,
                 from ../include/dlfcn.h:4,
                 from ../nss/nsswitch.h:28,
                 from ../include/nsswitch.h:1,
                 from ../inet/netgroup.h:22,
                 from ../include/netdb.h:193,
                 from gethstbyad.c:19:
../nss/getXXbyYY.c: In function 'gethostbyaddr':
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: can't find a
register in class 'R1_REGS' while reloading 'asm'
      asm volatile(       \
      ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:219:13: note: in
expansion of macro 'atomic_compare_and_exchange_val_acq'
   int val = atomic_compare_and_exchange_val_acq (futex, 1, 0);
             ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: can't find a
register in class 'R1_REGS' while reloading 'asm'
      asm volatile(       \
      ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:97:12: note: in expansion
of macro 'atomic_compare_and_exchange_val_acq'
      ret = atomic_compare_and_exchange_val_acq(mem, newval, oldval); \
            ^
../include/atomic.h:189:7: note: in expansion of macro
'atomic_compare_and_exchange_bool_acq'
      (atomic_compare_and_exchange_bool_acq (__atg5_memp, __atg5_value, \
       ^
../include/atomic.h:196:45: note: in expansion of macro 'atomic_exchange_acq'
 # define atomic_exchange_rel(mem, newvalue) atomic_exchange_acq (mem,
newvalue)
                                             ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:293:16: note: in
expansion of macro 'atomic_exchange_rel'
   ({ int val = atomic_exchange_rel (futex, 0);  \
                ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297:36: note: in
expansion of macro '__lll_unlock'
 #define lll_unlock(futex, private) __lll_unlock(&(futex), private)
                                    ^
../nptl/sysdeps/pthread/bits/libc-lockP.h:203:3: note: in expansion of macro
'lll_unlock'
   lll_unlock (NAME, LLL_PRIVATE)
   ^
../nss/getXXbyYY.c:144:3: note: in expansion of macro '__libc_lock_unlock'
   __libc_lock_unlock (lock);
   ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: 'asm' operand
has impossible constraints
      asm volatile(       \
      ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:219:13: note: in
expansion of macro 'atomic_compare_and_exchange_val_acq'
   int val = atomic_compare_and_exchange_val_acq (futex, 1, 0);
             ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: 'asm' operand
has impossible constraints
      asm volatile(       \
      ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:97:12: note: in expansion
of macro 'atomic_compare_and_exchange_val_acq'
      ret = atomic_compare_and_exchange_val_acq(mem, newval, oldval); \
            ^
../include/atomic.h:189:7: note: in expansion of macro
'atomic_compare_and_exchange_bool_acq'
      (atomic_compare_and_exchange_bool_acq (__atg5_memp, __atg5_value, \
       ^
../include/atomic.h:196:45: note: in expansion of macro 'atomic_exchange_acq'
 # define atomic_exchange_rel(mem, newvalue) atomic_exchange_acq (mem,
newvalue)
                                             ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:293:16: note: in
expansion of macro 'atomic_exchange_rel'
   ({ int val = atomic_exchange_rel (futex, 0);  \
                ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297:36: note: in
expansion of macro '__lll_unlock'
 #define lll_unlock(futex, private) __lll_unlock(&(futex), private)
                                    ^
../nptl/sysdeps/pthread/bits/libc-lockP.h:203:3: note: in expansion of macro
'lll_unlock'
   lll_unlock (NAME, LLL_PRIVATE)
   ^
../nss/getXXbyYY.c:144:3: note: in expansion of macro '__libc_lock_unlock'
   __libc_lock_unlock (lock);
   ^
make[2]: ***
[/home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os] Error
1
make[2]: Leaving directory `/home/aaro/los/work/shared/glibc-2.19/inet'
make[1]: *** [inet/subdir_lib] Error 2
make[1]: Leaving directory `/home/aaro/los/work/shared/glibc-2.19'
make: *** [all] Error 2

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

[aaro.koskinen at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

--- Comment #1 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
Created attachment 32655
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32655&action=edit
Pre-processed source.

Steps to reproduce:

hppa-linux-gnu-gcc gethstbyad.i -c -std=gnu99 -fgnu89-inline  -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g
-Wstrict-prototypes -fPIC -fexceptions

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

[aaro.koskinen at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

--- Comment #2 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
GLIVC 2.19 compiles fine with GCC 4.8.2.

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.1
            Summary|[4.9 Regression] hppa:      |[4.9/4.10 Regression] hppa:
                   |can't find a register in    |can't find a register in
                   |class 'R1_REGS' while       |class 'R1_REGS' while
                   |reloading 'asm'             |reloading 'asm'

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

[aaro.koskinen at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Aaro Koskinen <aaro.koskinen at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.8.3

--- Comment #3 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
The same error now also appears with 4.8.3 when compiling GLIBC 2.19.

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

[aaro.koskinen at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Aaro Koskinen <aaro.koskinen at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #4 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
I bisected this on gcc-4_8_branch to:

e990a321ced7f9b02c4065a2779bbf9eaa6c774f is the first bad commit
commit e990a321ced7f9b02c4065a2779bbf9eaa6c774f
Author: danglin <danglin@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Jan 8 02:01:50 2014 +0000

        PR target/59652
        * config/pa/pa.c (pa_legitimate_address_p): Return false before reload
        for 14-bit register offsets when INT14_OK_STRICT is false.



    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@206414
138bc75d-0d04-0410-961f-82ee72b054a4

With that commit reverted, GCC 4.8.3 builds latest GLIBC fine. I have not yet
tried if the same works with GCC 4.9.0.

Adding the commit author to CC.

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

[aaro.koskinen at iki dot fi]

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.

$ 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(
         ^
pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while reloading
'asm'
         asm volatile(
         ^
pr60925.c:6:9: error: 'asm' operand has impossible constraints
         asm volatile(
         ^
pr60925.c:6:9: error: 'asm' operand has impossible constraints
         asm volatile(
         ^

[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]

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

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

[carlos at systemhalted dot org]

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

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, ra
           Priority|P3                          |P4

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

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-21
                 CC|                            |law at redhat dot com
     Ever confirmed|0                           |1

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Carlos,

In general, you want to avoid using a register that is in a singleton class in
an asm explicitly in an asm.  While it works a hell of a lot better now than it
has in the past, there's still cases where you can put the compiler into a
situation where it can't figure out what to do.  Typically that happens when
you explicit clobber every register that GCC could potentially use to resolve a
reload.  And that's much more likely if you happen to clobber a register that
is a singleton in a class.

For the PA, %r1 is not fixed, but it is in a singleton class because it is the
only register that can be set by addil.  And ldil;add is not equivalent to
addil because of some *insanely* gross stuff done by the HP linker where it
will change addil <whatever>,r27 into addil <whatever>,r0, depending on what
subsection <whatever> is in.  THe linker isn't smart enough to do the same
transformation on an ldil/add sequence which should otherwise be equivalent.

Thus GCC has to put %r1 into its own class as a singleton.

%r1 will often be needed as a reload scratch register as well as an
intermediate for secondary reloads, most of the time to handle references to
data in static storage, but also to handle constants that may be shoved into
static storage.  Registers with this kind of need are handled specially by
reload and their "lifetime" essentially is the entire insn that triggered the
reload.  In this particular case, the lifetime is essentially the entire asm
statement.

So in this case, you have &lock being passed to lll_mutex_lock.  That's a
reference to static storage and thus *may* %r1 as a reload scratch register. 
That use as a reload scratch is seen as interfering with the %r1 in the clobber
list.

>From looking at the ASM you're trying to clobber all the call-clobbered
registers, presumably due to the hidden "call" in the asm (the
branch-and-link-external).  Note that you should probably be including %r2 in
that list.

My asm and PA-fu are a bit rusty, so it's not immediately clear how to do what
you want.  You could try changing r1 so that you're clobbering a register that
has to go into class "a".  At least in that case you might be able to use a
simple clobber ("=a") rather than an earlyclobber ("=&a") for the constraint. 
That gives GCC a bit more leeway in building the conflicts, but may still not
be enough.

Or get lock out of static memory or otherwise hide the fact that its in static
memory so that GCC won't try to create a direct reference to it in the asm.  I
think that's what David's workaround was in effect suggesting.  If by a level
of indirection you can prevent GCC from discovering that futex is in static
memory, then this problem should go away (its address will just be sitting in a
register and can be used directly). 

These are just potential workarounds for a reload issue that is highly unlikely
to ever get fixed.  If your asm clobber the entire set of call-clobbered
registers, you really don't leave reload enough leeway to handle reloads. 
Similarly if it clobbers everything in a particular class, then you run into
the same problem if there's an operand that requires a reload register of that
class.

This is probably a WONTFIX.

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

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
See c#11.

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

[carlos at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
For the record I made glibc use %r5 and saved/restored %r1 as required around
the syscall. I also added more clobbers in the event of future changes to the
kernel interface. This works around the "can't find a register in class FOO
while reloading 'asm'" error from the compiler.

The real culprit here is atomic.h in glibc and the asm in question is the
atomic compare and exchange that is being done via the light-weight kernel
syscall.