Bug 24661 - unable to find a register to spill in class NO_REGS on ia64
Summary: unable to find a register to spill in class NO_REGS on ia64
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.2.3
: P3 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-03 23:51 UTC by Mike Frysinger
Modified: 2005-11-09 15:57 UTC (History)
4 users (show)

See Also:
Host:
Target: ia64-linux-gnu
Build:
Known to work: 4.1.0
Known to fail: 3.3.2 3.3.6 3.4.4 4.0.2 4.0.3
Last reconfirmed:


Attachments
reduced test case, sym.c (461 bytes, text/plain)
2005-11-03 23:51 UTC, Mike Frysinger
Details
full test case from quake3 source quake3-register-spill-insn.tar.bz2 (8.21 KB, application/octet-stream)
2005-11-03 23:52 UTC, Mike Frysinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2005-11-03 23:51:01 UTC
trying to build quake3 on ia64 ... reduced test case looks like this:

$ gcc -O2 -c sym.c
sym.c: In function `vtoa':
sym.c:28: error: unable to find a register to spill in class `FR_REGS'
sym.c:28: error: this is the insn:
(insn 12 3 13 0 (set (reg:DF 134 f6 [343])
        (float_truncate:DF (subreg:XF (reg/v:TI 112 in0 [orig:340 v ] [340]) 0))) 39 {truncxfdf2} (insn_list 3 (nil))
    (expr_list:REG_DEAD (reg/v:TI 112 in0 [orig:340 v ] [340])
        (nil)))
sym.c:28: confused by earlier errors, bailing out

tested Gentoo 3.3.2 / 3.3.6 / 3.4.4 / 4.0.2, all fail same way
Comment 1 Mike Frysinger 2005-11-03 23:51:31 UTC
Created attachment 10138 [details]
reduced test case, sym.c
Comment 2 Mike Frysinger 2005-11-03 23:52:33 UTC
Created attachment 10139 [details]
full test case from quake3 source quake3-register-spill-insn.tar.bz2
Comment 3 Andrew Pinski 2005-11-04 00:07:56 UTC
I cannot reproduce this on the mainline.  Are you sure that this is not due to a modification that gentoo has done?
Comment 4 Mike Frysinger 2005-11-04 00:12:09 UTC
i had a SuSE guy report the samething, but i'll go ahead and rebuild a vanilla 4.0.2 to be sure
Comment 5 Mike Frysinger 2005-11-04 00:55:59 UTC
ok, gcc-4.0.2 on Gentoo with no Gentoo patches fails same way

i'll see about creating a Debian chroot to doubly verify
Comment 6 Andrew Pinski 2005-11-04 01:06:57 UTC
Then maybe this has been fixed in 4.1.0 already.
Comment 7 Mike Frysinger 2005-11-04 01:46:51 UTC
if that's the case, since this doesnt seem to be a regression (unless it worked in like 3.2.x or older), does that mean i'm sol with 3.4.x/4.0.x ? :)
Comment 8 Mike Frysinger 2005-11-04 02:09:00 UTC
yes, debian 3.3.6-10 (3.3.6) and 3.4.4-9 (3.4.5 20051015) both fail in the same way ... debian's 4.0.3 (4.0.3 20051023) however fails in a different way:

sym.c: In function 'vtoa':
sym.c:28: internal compiler error: in find_valid_class, at reload.c:719
Please submit a full bug report,

i'll see about installing gcc-4.1 on my Gentoo box
Comment 9 Michael Matz 2005-11-09 14:49:32 UTC
A shorter testcase (which at least breaks on SuSEs 3.3-hammer compiler) is:
---------------------------------------
typedef union value {
        long double d;
} Value;

double ld2d(Value v) {
        return v.d;
}
---------------------------------------

The problem seems to be that the register containing the union is TImode,
which gets converted to TFmode via subreg, which in turn is truncated to
DFmode via float_truncate, which somehow confuses gcc.
Comment 10 Andrew Pinski 2005-11-09 15:23:06 UTC
Hmm, do we have an ABI change in 4.1:
We get in 4.1.0:
ld2d:
        .prologue
        .body
        fnorm.d f8 = f8
        br.ret.sptk.many b0
Comment 11 Michael Matz 2005-11-09 15:32:51 UTC
You mean ABI change, because the input register seems to be f8, instead of
in0 (as would be need for this union)?  I'm not sure, but it looks fishy
at least.
Comment 12 Andrew Pinski 2005-11-09 15:57:42 UTC
(In reply to comment #11)
> You mean ABI change, because the input register seems to be f8, instead of
> in0 (as would be need for this union)?  I'm not sure, but it looks fishy
> at least.
Actually it is not an ABI change as the 3.4's RTL looks like:
(insn 3 2 4 (set (reg/v:TI 340 [ v ])
        (reg:TI 136 f8 [ v ])) -1 (nil)
    (nil))

so it comes in as f8.

Note 4.0.3 20051105 fails the same way as your 4.0.3 does

So closing as fixed as this is not a regression.
Note gcc 4.1 produces the RTL as:
(insn 6 11 7 0 (set (reg:XF 340)
        (reg:XF 136 f8 [ v ])) -1 (nil)
    (nil))

Which is in the correct mode right away.