[linaro regression] alsa-tools FTBFS with error "unable to find a register to spill in class ‘AREG’"

Bug #1135633 reported by David Henningsson on 2013-02-28
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Fix Released
High
Kumar Venkataramanan
gcc
Fix Released
Medium
alsa-tools (Ubuntu)
Undecided
Unassigned
gcc-4.7 (Ubuntu)
High
Unassigned

Bug Description

(Tested on amd64)

apt-get source alsa-tools
cd alsa-tools-<version>
dpkg-buildpackage -b

x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -MT ac3spdif.o -MD -MP -MF .deps/ac3spdif.Tpo -c -o ac3spdif.o ac3spdif.c
ac3spdif.c: In function ‘output_spdif’:
ac3spdif.c:166:1: error: unable to find a register to spill in class ‘AREG’
ac3spdif.c:166:1: error: this is the insn:
(insn 154 419 71 4 (parallel [
            (set (reg:DI 2 cx [222])
                (const_int 0 [0]))
            (set (reg/f:DI 5 di [220])
                (plus:DI (ashift:DI (reg:DI 2 cx [222])
                        (const_int 3 [0x3]))
                    (reg/f:DI 1 dx [219])))
            (set (mem/c:BLK (reg/f:DI 1 dx [219]) [0 buf+0 S6144 A256])
                (const_int 0 [0]))
            (use (reg:DI 4 si [221]))
            (use (reg:DI 2 cx [222]))
        ]) /usr/include/x86_64-linux-gnu/bits/string3.h:97 888 {*rep_stosdi_rex64}
     (expr_list:REG_DEAD (reg:DI 4 si [221])
        (expr_list:REG_DEAD (reg/f:DI 1 dx [219])
            (expr_list:REG_UNUSED (reg:DI 2 cx [222])
                (expr_list:REG_UNUSED (reg/f:DI 5 di [220])
                    (nil))))))
ac3spdif.c:166: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccGmnHxr.out file, please attach this to your bugreport.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: gcc 4:4.7.2-1ubuntu8
ProcVersionSignature: Ubuntu 3.8.0-2.6-generic 3.8.0-rc4
Uname: Linux 3.8.0-2-generic x86_64
ApportVersion: 2.8-0ubuntu4
Architecture: amd64
Date: Thu Feb 28 12:45:50 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-11-09 (110 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121109)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gcc-defaults
UpgradeStatus: No upgrade log present (probably fresh install)

David Henningsson (diwic) wrote :
David Henningsson (diwic) wrote :

Attaching the file the error report told me to.

Matthias Klose (doko) wrote :

> ac3spdif.c:166: confused by earlier errors, bailing out
> Preprocessed source stored into /tmp/ccGmnHxr.out file, please attach this to your bugreport.

and?

affects: gcc-defaults (Ubuntu) → gcc-4.7 (Ubuntu)
Changed in alsa-tools (Ubuntu):
status: New → Incomplete
Matthias Klose (doko) wrote :

meh, the bug mail doesn't show the attachment

Changed in alsa-tools (Ubuntu):
status: Incomplete → New
Matthias Klose (doko) wrote :

confirmed, can't see this with the FSF branch, only with the Linaro branch.

Changed in gcc-4.7 (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Matthias Klose (doko) wrote :

works on armhf, fails on x86, looks like a regression.

summary: - alsa-tools FTBFS with error "unable to find a register to spill in class
- ‘AREG’"
+ [linaro regression] alsa-tools FTBFS with error "unable to find a
+ register to spill in class ‘AREG’"
Changed in gcc-linaro:
status: New → Confirmed
importance: Undecided → High

Reduced test case which triggers on gcc-linaro 4.7 in the same way.

Also managed to trigger this on upstream GCC trunk (but with an ICE in LRA):

$ gcc -O2 -c besttry.c
besttry.c: In function ‘output_spdif’:
besttry.c:20:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1268
 }
 ^
0x7f1cf8 assign_by_spills
 /work/sources/gcc-fsf/master/gcc/lra-assigns.c:1268
0x7f29b3 lra_assign()
 /work/sources/gcc-fsf/master/gcc/lra-assigns.c:1425
0x7eebe1 lra(_IO_FILE*)
 /work/sources/gcc-fsf/master/gcc/lra.c:2307
0x7b6e18 do_reload
 /work/sources/gcc-fsf/master/gcc/ira.c:4619
0x7b6e18 rest_of_handle_reload
 /work/sources/gcc-fsf/master/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Created attachment 29552
Test case

The attached test case ICEs on trunk (svn revision: 196329) as follows:

$ x86_64-unknown-linux-gnu-gcc -O2 besttry.c
besttry.c: In function ‘output_spdif’:
besttry.c:26:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1268
 }
 ^
0x7f1cf8 assign_by_spills
 /work/sources/gcc-fsf/master/gcc/lra-assigns.c:1268
0x7f29b3 lra_assign()
 /work/sources/gcc-fsf/master/gcc/lra-assigns.c:1425
0x7eebe1 lra(_IO_FILE*)
 /work/sources/gcc-fsf/master/gcc/lra.c:2307
0x7b6e18 do_reload
 /work/sources/gcc-fsf/master/gcc/ira.c:4619
0x7b6e18 rest_of_handle_reload
 /work/sources/gcc-fsf/master/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Believe this is a target issue as the original test case does not trigger the failure for arm-none-linux-gnueabihf

GCC PR 56484 added to track the upstream issue.

Changed in gcc-linaro:
assignee: nobody → Kumar Venkataramanan (venkataramanan-kumar)
In , Doko-v (doko-v) wrote :

I can't reproduce this with r196236

Forgot to add gcc -v output:
Using built-in specs.
COLLECT_GCC=/work/builds/gcc-fsf-master/tools/bin/x86_64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/work/builds/gcc-fsf-master/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /work/sources/gcc-fsf/master/configure --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/work/builds/gcc-fsf-master/tools --enable-languages=c,c++,fortran --with-ppl-include=/usr/include/x86_64-linux-gnu
Thread model: posix
gcc version 4.8.0 20130228 (experimental) (GCC)

(In reply to comment #1)
> I can't reproduce this with r196236

I tried with some old revisions I had on a SLES 11 SP1 machine.

I am getting this issue with r193549 at lra-assigns.c.
reload.c spill failure when I use 190150 (does not have LRA). This seems to be a long known issue in trunk.

I am triaging further

Changed in gcc:
importance: Unknown → Medium
status: Unknown → New

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188526
but it was merely latent before that, so it isn't LRA bug, because it fails with reload equally.
I think the problem is in combine, where we have:
ax = call ...
flags = r59 != 0
r60 = flags >= 0 ? ax : r59
r65 = buf
r68 = 768
rep stosd [r65 .. r65 + r68 - 4] = 0
r59 = r60

and the combiner combines the r60 = flags >= 0 ? ax : r59 instruction with
r59 = r60 into r59 = flags >= 0 ? ax : r59 instruction in the last spot, thus extending the lifetime of the ax and flags hard registers across various other instructions.

-fno-tree-coalesce-vars for workarround

-ftree-coalesce-vars is enabled in FSF GCC trunk by default. Disabling it will prevent the issue occuring for reduced test case in GCC FSF trunk.

I believe this flag is not available in GCC branch.

./install-linaro-4.7-2013.02-01/bin/gcc -O2 test.c -fno-tree-coalesce-vars passes that test case.

I think teh flag is included for gcc4.7-linaro-4.7-2013.02-01

GCC 4.7 FSF branch does not support -ftree-coalesce-vars till now. But GCC 4.7-linaro supports that. Disabling (-fno-tree-coalesce-var) will solve this issue as of now.

(In reply to comment #4)

> and the combiner combines the r60 = flags >= 0 ? ax : r59 instruction with
> r59 = r60 into r59 = flags >= 0 ? ax : r59 instruction in the last spot, thus
> extending the lifetime of the ax and flags hard registers across various other
> instructions.

But AX is member of likely spilled class, so combine should take some more care with this insn. Should we just prevent propagations of all insns that mention likely spilled hard regs?

Actually, looking more at this, I'd say combiner is innocent here, the problem is earlier , during ce1 pass, which transforms:
   16: ax:SI=call [`output_play'] argc:0
      REG_DEAD di:DI
      REG_DEAD si:SI
   17: r60:SI=ax:SI
      REG_DEAD ax:SI
   18: flags:CCGOC=cmp(r59:SI,0)
   19: pc={(flags:CCGOC>=0)?L21:pc}
      REG_DEAD flags:CCGOC
      REG_BR_PROB 0x1c84
   20: NOTE_INSN_BASIC_BLOCK 4
    6: r60:SI=r59:SI
      REG_DEAD r59:SI
   21: L21:
   22: NOTE_INSN_BASIC_BLOCK 5
into:
   16: ax:SI=call [`output_play'] argc:0
      REG_DEAD di:DI
      REG_DEAD si:SI
   17: r60:SI=ax:SI
      REG_DEAD ax:SI
   18: flags:CCGOC=cmp(r59:SI,0)
   53: flags:CCGOC=cmp(r59:SI,0)
   54: r60:SI={(flags:CCGOC>=0)?ax:SI:r59:SI}
   22: NOTE_INSN_BASIC_BLOCK 4

i.e. does what combiner tries to avoid with hard registers. I don't understand
why it can't use r60:SI instead of ax:SI.

Created attachment 29583
gcc48-pr56484.patch

Untested fix.

Author: jakub
Date: Tue Mar 5 22:25:43 2013
New Revision: 196478

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196478
Log:
 PR rtl-optimization/56484
 * ifcvt.c (noce_process_if_block): If else_bb is NULL, avoid extending
 lifetimes of hard registers on small register class machines.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr56484.c
Modified:
    trunk/gcc/ifcvt.c

Fixed.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.7 - 4.7.2-22ubuntu3

---------------
gcc-4.7 (4.7.2-22ubuntu3) raring; urgency=low

  * Update to SVN 20130307 (r196523) from the gcc-4_7-branch.
    - Fix PR libstdc++/56012, PR libstdc++/56011, PR target/56529 (SH),
      PR tree-optimization/55481, PR middle-end/52888,
      PR tree-optimization/56443, PR c++/56543.
  * Fix PR rtl-optimization/56484 (Venkataramanan Kumar, Linaro only).
    LP: #1135633.
 -- Matthias Klose <email address hidden> Fri, 08 Mar 2013 00:40:18 +0800

Changed in gcc-4.7 (Ubuntu):
status: Confirmed → Fix Released
Changed in gcc-linaro:
milestone: none → 4.7-2013.03
status: Confirmed → Fix Released
Changed in gcc:
status: New → Fix Released
Changed in alsa-tools (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.