public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
       [not found] <109930000.1035487357@warlock.codesourcery.com>
@ 2002-10-25 20:13 ` David Edelsohn
  2002-10-25 23:54   ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: David Edelsohn @ 2002-10-25 20:13 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc

	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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
  2002-10-25 20:13 ` GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX David Edelsohn
@ 2002-10-25 23:54   ` Richard Henderson
  2002-10-26  2:52     ` David Edelsohn
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2002-10-25 23:54 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Mark Mitchell, gcc

On Fri, Oct 25, 2002 at 06:32:01PM -0400, David Edelsohn wrote:
> 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}

Note that there is only one input reload because there is only one
operand visible to reload.  It's an unfortunate fact that match_parallel
cannot work with arbitrary instructions before reload.

This was "solved" in the ARM backend by using separate patterns for
2 to 4 input registers.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
  2002-10-25 23:54   ` Richard Henderson
@ 2002-10-26  2:52     ` David Edelsohn
  2002-10-26  2:57       ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: David Edelsohn @ 2002-10-26  2:52 UTC (permalink / raw)
  To: Richard Henderson, Mark Mitchell, gcc

>>>>> Richard Henderson writes:

Richard> Note that there is only one input reload because there is only one
Richard> operand visible to reload.  It's an unfortunate fact that match_parallel
Richard> cannot work with arbitrary instructions before reload.

	This worked in GCC 2.95 and works in the trunk.  Does this ring a
bell with anyone why the replacements aren't complete on the GCC 3.2
branch?

Thanks, David

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
  2002-10-26  2:52     ` David Edelsohn
@ 2002-10-26  2:57       ` Richard Henderson
  2002-10-26  3:03         ` David Edelsohn
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2002-10-26  2:57 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Mark Mitchell, gcc

On Fri, Oct 25, 2002 at 08:20:52PM -0400, David Edelsohn wrote:
> 	This worked in GCC 2.95 and works in the trunk.

Oh, that's right, things broke on arm due to regrename.c.
POWER doesn't have ordered register numbering issues, does it?
If not, I have no idea what broke.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
  2002-10-26  2:57       ` Richard Henderson
@ 2002-10-26  3:03         ` David Edelsohn
  2002-10-27  6:07           ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: David Edelsohn @ 2002-10-26  3:03 UTC (permalink / raw)
  To: Richard Henderson, Mark Mitchell, gcc

>>>>> Richard Henderson writes:

Richard> Oh, that's right, things broke on arm due to regrename.c.
Richard> POWER doesn't have ordered register numbering issues, does it?
Richard> If not, I have no idea what broke.

	What does "ordered register numbering issues" mean?  The STRING
instructions are equivalent to GCC concept of load_multiple and
store_multiple.  The instructions load and store into consecutive
registers.

David

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX
  2002-10-26  3:03         ` David Edelsohn
@ 2002-10-27  6:07           ` Richard Henderson
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2002-10-27  6:07 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Mark Mitchell, gcc

On Fri, Oct 25, 2002 at 08:33:57PM -0400, David Edelsohn wrote:
> 	What does "ordered register numbering issues" mean?  The STRING
> instructions are equivalent to GCC concept of load_multiple and
> store_multiple.  The instructions load and store into consecutive
> registers.

Ah, well then yes, you'll have the same problems.  But this
is not the problem you're having here.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2002-10-26 16:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <109930000.1035487357@warlock.codesourcery.com>
2002-10-25 20:13 ` GCC 3.2 branch libstdc++ abi_check.cc bootstrap failure on AIX David Edelsohn
2002-10-25 23:54   ` Richard Henderson
2002-10-26  2:52     ` David Edelsohn
2002-10-26  2:57       ` Richard Henderson
2002-10-26  3:03         ` David Edelsohn
2002-10-27  6:07           ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).