[Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
--- Comment #8 from Carlos O'Donell ---
On Sun, May 25, 2014 at 2:30 PM, John David Anglin
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 ---
>> 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 c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Carlos O'Donell changed: What|Removed |Added CC||carlos at systemhalted dot | |org --- Comment #8 from Carlos O'Donell 2012-11-12 18:29:12 UTC --- The glibc community is aware of this issue. I've added it to our generic todo list from which developers can help coordinate an implementation. http://sourceware.org/glibc/wiki/Development_Todo/Generic
[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
--- Comment #4 from carlos at systemhalted dot org 2010-01-31 16:54 --- That is correct, all glibc targets must provide the current version if libgcc_s.so. The NPTL implementation of pthread_cancel_init will dlopen that current version of libgcc_s.so and use the unwinder implementation from that library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42850
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #8 from carlos at systemhalted dot org 2009-01-12 15:02 --- Dave, I've been building parts of glibc's vfprintf code with -fno-delayed-branch for hppa because of bugs in DBR. I never filed a bug because it was almost impossible for me to reduce the vfprintf code (large file, large tables, long jumps). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug target/36551] Failure to compile __thread variable.
--- Comment #2 from carlos at systemhalted dot org 2008-06-18 02:35 --- Yes, I just realized there were no TARGET_64BIT TLS patterns in config/pa/pa.md. I'm closing the bug as invalid. I'll take this up seperately. We'll have to define call sequences for the 64-bit address loads etcs. -- carlos at systemhalted dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36551
[Bug target/36551] New: Failure to compile __thread variable.
Steps to reproduce:
cat >> test.c <http://gcc.gnu.org/bugs.html> for instructions.
Expected:
- Compiler correctly compiles the code.
Observed:
- ICE trying to compile code with __thread keyword.
hppa does have support for thread local storage, but it's never been tested on
the 64-bit compiler.
I came across this error while trying to port glibc to hppa64-linux-gnu during
a 64-bit userspace bring-up.
--
Summary: Failure to compile __thread variable.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at systemhalted dot org
GCC build triplet: hppa-linux-gnu
GCC host triplet: hppa64-linux-gnu
GCC target triplet: hppa64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36551
[Bug middle-end/28749] Miscompilation of glibc/stdio-common/vfprintf.c, invalid delay slot fill.
--- Comment #3 from carlos at systemhalted dot org 2006-08-16 06:48 ---
Dumping vfprintf.c compile with -S and -da
; basic block 131
.LBE379:
.LBB380:
.LBB380:
; vfprintf.c:1448
.loc 2 1448 0
ldw 8(%r3),%r28
ldil L'16384,%r22
ldb 0(%r28),%r21
.LVL339:
ldo -6804(%r22),%r22
extrs %r21,31,8,%r28
addl %r22,%r3,%r22
stw %r28,0(%r22)
ldo -32(%r21),%r20
ldi 90,%r28
extru %r20,31,8,%r20
; vfprintf.c:1562
.loc 2 1562 0
; vfprintf.c:1448
.loc 2 1448 0
comb,<< %r28,%r20,.L1104
ldil L'16384,%r21
Incorrect delay slot fill.
; basic block 313
.LVL557:
.L1104:
.LBE425:
.LBE418:
.LBE417:
.LBB426:
; vfprintf.c:1562
.loc 2 1562 0
ldo -6804(%r21),%r21
addl %r21,%r3,%r21
ldw 0(%r21),%r21
bb 313 is missing the first insn.
The output of vfprintf.c.157r.dbr shows:
(barrier 18544 18543 2803)
(note 2803 18544 14801 ("vfprintf.c") 1561)
(note 14801 2803 14802 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5 [orig:281
size ] [281])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14802 14801 14803 ( function_done (nil)) NOTE_INSN_VAR_LOCATION)
(note 14803 14802 14804 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5
[orig:280 size ] [280])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14804 14803 14805 ( __self (expr_list:REG_DEP_TRUE (reg/v/f:SI 5 %r5
[orig:364 __self ] [364])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14805 14804 14806 ( ptr (expr_list:REG_DEP_TRUE (reg/v/f:SI 21 %r21
[orig:346 ptr ] [346])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14806 14805 2804 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5 [orig:282
size ] [282])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(code_label/s 2804 14806 2805 242 ("do_form_unknown") [1 uses])
(note 2805 2804 2806 [bb 313] NOTE_INSN_BASIC_BLOCK)
(note 2806 2805 14807 ("vfprintf.c") 1562)
(note 14807 2806 19223 ( ptr (nil)) NOTE_INSN_VAR_LOCATION)
(code_label 19223 14807 8862 1104 "" [2 uses])
(insn 8862 19223 8863 vfprintf.c:1562 (set (reg/f:SI 21 %r21)
(plus:SI (reg/f:SI 21 %r21)
(const_int -6804 [0xe56c]))) 114 {addsi3} (nil)
(expr_list:REG_EQUAL (const_int 9580 [0x256c])
(nil)))
And the set has been moved into bb 131
(insn 19224 831 14145 vfprintf.c:1562 (sequence [
(jump_insn:TI 833 831 8861 vfprintf.c:1448 (set (pc)
(if_then_else (gtu (reg:SI 20 %r20 [782])
(reg:SI 28 %r28 [783]))
(label_ref:SI 19223)
(pc))) -1 (nil)
(expr_list:REG_BR_PRED (const_int 4 [0x4])
(expr_list:REG_DEAD (reg:SI 20 %r20 [782])
(expr_list:REG_DEAD (reg:SI 28 %r28 [783])
(expr_list:REG_EQUAL (if_then_else (gtu (reg:SI 20
%r20 [782])
(const_int 90 [0x5a]))
(label_ref:SI 19223)
(pc))
(expr_list:REG_BR_PROB (const_int 5000
[0x1388])
(nil)))
(insn/s:TI 8861 833 14145 (set (reg/f:SI 21 %r21)
(const_int 16384 [0x4000])) 37 {*pa.md:2482} (nil)
(nil))
]) -1 (nil)
(nil))
While vfprintf.c.156r.barriers shows:
(barrier 12266 12265 2803)
(note 2803 12266 14801 ("vfprintf.c") 1561)
(note 14801 2803 14802 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5 [orig:281
size ] [281])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14802 14801 14803 ( function_done (nil)) NOTE_INSN_VAR_LOCATION)
(note 14803 14802 14804 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5
[orig:280 size ] [280])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14804 14803 14805 ( __self (expr_list:REG_DEP_TRUE (reg/v/f:SI 5 %r5
[orig:364 __self ] [364])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14805 14804 14806 ( ptr (expr_list:REG_DEP_TRUE (reg/v/f:SI 21 %r21
[orig:346 ptr ] [346])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 14806 14805 2804 ( size (expr_list:REG_DEP_TRUE (reg/v:SI 5 %r5 [orig:282
size ] [282])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(code_label/s 2804 14806 2805 242 ("do_form_unknown") [5 uses])
(note 2805 2804 2806 [bb 313] NOTE_INSN_BASIC_BLOCK)
(note 2806 2805 8861 ("vfprintf.c") 1562)
(insn:TI 8861 2806 14807 vfprintf.c:1562 (set (reg/f:SI 21 %r21)
(const_int 16384 [0x4000])) 37 {*pa.md:2482} (nil)
(nil))
That is is still present in the correct basic block before dbr, and the label
and barriers are present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28749
[Bug middle-end/28749] Miscompilation of glibc/stdio-common/vfprintf.c, invalid delay slot fill.
--- Comment #2 from carlos at systemhalted dot org 2006-08-16 05:56 --- Building vfprintf.c with -fno-delayed-branch is a workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28749
[Bug c/28749] New: Miscompilation of glibc/stdio-common/vfprintf.c
This is a regression since 4.1 and 4.0 compile vfprintf.c correctly.
I am using gcc trunk to build libc / libc-ports head. I have a regression in
tst-printfsz which is part of the glibc testsuite. The problem is a
miscompilation of glibc/stdio-common/vfprintf.c by GCC.
The bug is as follows:
Location 1 jumps to location 2.
Compiler moves first insn at location 2 to location 1's branch delay slot.
Location 3 computes a goto to location 2.
Because the first insn at location 2 was moved, the program now crashes.
The concrete debugging example:
The first insn "ldil L%4000,r21" is moved to location 1's branch delay slot.
Location 3:
468cc: ea a0 c0 02 bv,n r0(r21)
r21 == (0x403d3000 + 0x4928c) and is part of "goto *ptr"
Location 1:
478b4: 82 9c 93 a4 cmpb,<< ret0,r20,4928c <_IO_vfprintf+0x322c>
478b8: 22 a2 00 00 ldil L%4000,r21
Location 2:
4928c: 36 b5 0a d9 ldo -1a94(r21),r21
49290: 08 75 0a 15 add,l r21,r3,r21
49294: 0e a0 10 95 ldw 0(r21),r21
49298: 92 a0 30 00 cmpiclr,<> 0,r21,r0
4929c: e8 1e 0f 45 b,l 46a44 <_IO_vfprintf+0x9e4>,r0
492a0: 34 15 3f ff ldi -1,r21
The code at location 3 jumps to location 2, and does not execute the required
"ldil L%4000,r21"
The computed goto should create edges to all the label addresses taken by &&,
and that should prevent the branch delay slot from fill from occuring.
I am recompiling glibc with CFLAGS-vfprintf.c += -fno-delayed-branch to see if
it passes the tst-printfsz test.
How should I proceed on this issue? I have tried to create a testcase, but I
haven't been successfull.
--
Summary: Miscompilation of glibc/stdio-common/vfprintf.c
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at systemhalted dot org
GCC build triplet: hppa-linux
GCC host triplet: hppa-linux
GCC target triplet: hppa-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28749
