This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 25 Oct 2002 18:32:01 -0400
- Subject: Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
The GCC 3.2.1 branch does not bootstrap because of an ICE while
compiling libstdc++-v3/testsuite/abi_check.cc with the -mcpu=power option.
The failure does not occur on the trunk. I originally thought that this
failure was specific to the POWER architecture, so I considered it
relatively low priority, but it turns out that the failure is associate
with the "string" instructions available in the PowerPC architecture as
well. The RTL for the string instruction is not having all occurrances of
the pseudo containing the base address replaced by the hard register.
Reloads for insn # 1856
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 1 r1)
(const_int 520 [0x208]))
BASE_REGS, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (plus:SI (reg/f:SI 1 r1)
(const_int 520 [0x208]))
reload_reg_rtx: (reg:SI 11 r11)
(insn 1856 16488 16458 (parallel[
(set (reg:SI 4 r4)
(mem/s:SI (reg:SI 11 r11) [0 S4 A128]))
(set (reg:SI 5 r5)
(mem/s:SI (plus:SI (reg/f:SI 929)
(const_int 4 [0x4])) [0 S4 A32]))
(set (reg:SI 6 r6)
(mem/s:SI (plus:SI (reg/f:SI 929)
(const_int 8 [0x8])) [0 S4 A64]))
(set (reg:SI 7 r7)
(mem/s:SI (plus:SI (reg/f:SI 929)
(const_int 12 [0xc])) [0 S4 A32]))
] ) 322 {*rs6000.md:8737} (insn_list:REG_DEP_OUTPUT 1843 (insn_list:REG_DEP_OUTPUT 1846 (insn_list 1842 (insn_list:REG_DEP_ANTI 1849 (nil)))))
(nil))
This lack of replacement occurs for RTL representing other string
instructions as well .
Is the RTL for the register suppose to be shared so that one
substitution is suppose to replace all pseudos or is each occurance
replaced individually? Because the failure does not occur on the trunk, I
tried backporting reload patches, but that did not seem to have an effect.
I have created a high priority PR for this in the bugs database.
David