[Bug target/65249] New: unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[Bug target/65249] New: unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

            Bug ID: 65249
           Summary: unable to find a register to spill in class 'R0_REGS'
                    when compiling protobuf on sh4
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
            Target: sh*-*-*

Hello!

Here's another package that previously successfully built on Debian sh4 and now
fails with an apparent compiler error:

/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..  
-D_FORTIFY_SOURCE=2 -pthread -Wall -Wwrite-strings -Woverloaded-virtual
-Wno-sign-compare  -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -c -o google/protobuf/descriptor.pb.lo
google/protobuf/descriptor.pb.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -pthread
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -c
google/protobuf/descriptor.pb.cc  -fPIC -DPIC -o
google/protobuf/.libs/descriptor.pb.o
google/protobuf/descriptor.pb.cc: In member function 'virtual
google::protobuf::Metadata
google::protobuf::OneofDescriptorProto::GetMetadata() const':
google/protobuf/descriptor.pb.cc:3448:1: error: unable to find a register to
spill in class 'R0_REGS'
 }
 ^
google/protobuf/descriptor.pb.cc:3448:1: error: this is the insn:
(insn 102 127 85 7 (set (reg:SI 1 r1 [+4 ])
        (mem/f/c:SI (plus:SI (reg/f:SI 1 r1 [197])
                (reg:SI 12 r12)) [5 OneofDescriptorProto_reflection_+0 S4
A32])) google/protobuf/descriptor.pb.cc:3448 257 {movsi_ie}
     (expr_list:REG_DEAD (reg/f:SI 1 r1 [197])
        (nil)))
google/protobuf/descriptor.pb.cc:3448: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccdkVmsq.out file, please attach this to
your bugreport.

Build log here [1], precompiled source attached.

Cheers,

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=protobuf&arch=sh4&ver=2.6.1-1&stamp=1425065627

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #1 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 34898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34898&action=edit
Preprocessed source file for protobuf 2.6.1 (gzipped)

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-28
                 CC|                            |kkojima at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Compiling attachment 34901 on sh-elf with '-m4 -ml -O2 -fPIC
-fstack-protector-strong':

4.9: NG
5: NG
5 -mlra: OK

On 4.8 there is no option -fstack-protector-strong.  Omitting this option seems
to be a possible workaround.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
For some reason r0 is live throughout the whole basic block where the problem
occures.  The basic block starts with:

(note 36 35 38 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(note 38 36 39 5 NOTE_INSN_DELETED)
(note 39 38 70 5 NOTE_INSN_DELETED)
(insn 70 39 133 5 (set (reg:SI 0 r0)
        (const_int 0 [0])) ccdkVmsq_1.out:48 252 {movsi_ie}
     (nil))

When using LRA, r0 is spilled to stack, and PIC_REG (r12) is copied to r0 for
the mem load.  r0 is then reloaded from stack, but rematerialized and converted
into a load of constant.

        mov     r12,r2
        add     r11,r2
        mov     #0,r0         <<<< 
        mov.l   .L25,r1
        mov.l   @r2,r2
        mov.l   r0,@r15       <<<<
        mov     r12,r0        <<<<
        mov.l   @(60,r10),r3
        mov.l   @r2,r7
        cmp/eq  r3,r7
        mov     #0,r3
        mov     #0,r7
        mov.l   @(r0,r1),r1   <<<<
        bf/s    .L16
        mov     #0,r0         <<<<

        add     #12,r15
        ...

If I'm not mistaken, the above can be done better as:
        mov     r11,r0
        mov.l   @(r0,r12),r2
        mov.l   .L25,r0
        mov.l   @(60,r10),r3
        mov.l   @r2,r7
        cmp/eq  r3,r7
        mov     #0,r3
        mov     #0,r7
        mov.l   @(r0,r12),r1
        bf/s    .L16
        mov     #0,r0

        add     #12,r15
        ...

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
On trunk, I've tried adding this:

(define_split
  [(set (match_operand:SI 0 "arith_reg_dest")
    (mem:SI (plus:SI (match_operand:SI 1 "arith_reg_operand")
             (match_operand:SI 2 "arith_reg_operand"))))]
  "TARGET_SH1 && can_create_pseudo_p ()"
  [(const_int 0)]
{
  rtx tmp = gen_reg_rtx (SImode);
  rtx r0 = gen_rtx_REG (SImode, R0_REG);

  emit_move_insn (tmp, r0);
  emit_move_insn (r0, operands[1]);

  rtx mem = replace_equiv_address (XEXP (PATTERN (curr_insn), 1),
                   gen_rtx_PLUS (SImode, r0, operands[2]),
                   false);
  emit_move_insn (operands[0], mem);
  emit_move_insn (r0, tmp);
})

to workaround the r0 spill failure for the (r0+rm) mem load.
Then another spill failure with the 'cmp/eq #imm,r0' insn popped up.  So I've
added this:

(define_split
  [(set (reg:SI T_REG)
    (eq:SI (match_operand:SI 1 "arith_reg_operand")
           (match_operand:SI 2 "const_int_operand")))]
  "TARGET_SH1 && can_create_pseudo_p ()
   && satisfies_constraint_I08 (operands[2])"
  [(const_int 0)]
{
  rtx tmp = gen_reg_rtx (SImode);
  rtx r0 = gen_rtx_REG (SImode, R0_REG);

  emit_move_insn (tmp, r0);
  emit_move_insn (r0, operands[1]);
  emit_insn (gen_cmpeqsi_t (r0, operands[2]));
  emit_move_insn (r0, tmp);
})

With those two split patterns added attachment 34901 compiles.

This is basically the same trick as done in prepare_move_operands for QIHImode
loads with displacement.  Effectively it pre-allocates the r0 uses and shortens
the r0 live ranges.
When compiling with LRA the resulting code seems a bit better (comment #4),
too.  I haven't checked the impact on average code (CSiBE) though.

While we probably could add those two patterns as a quick fix, I don't think
it's a great solution, because we'd actually need to add such patterns for
*all* insns that have the 'z'/r0 constraint.  In this case it might be better
to add an SH specific RTL pass before IRA which can do such kind of RA
preparations to improve the RA result/process.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #5)
> 
> While we probably could add those two patterns as a quick fix, I don't think
> it's a great solution, because we'd actually need to add such patterns for
> *all* insns that have the 'z'/r0 constraint.  In this case it might be
> better to add an SH specific RTL pass before IRA which can do such kind of
> RA preparations to improve the RA result/process.

Actually, that pass might also cover the issue in PR 64785.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 34902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34902&action=edit
Various R0 pre-alloc splits

I've tried compiling CSiBE with the two split patterns in comment #5 ...
It's a can of worms.  I'm dumping my current state as a patch here, maybe it's
helpful in some way.  I ended up adding one r0 split pattern after another, but
probably some are still missing.

bzip2 (haven't tried anything else so far) fails with:

internal compiler error: in spill_failure, at reload1.c:2143
error: this is the insn:
(insn 8965 8964 8966 70 (set (mem:SI (plus:SI (reg:SI 0 r0)
                (reg:SI 945 [ D.5064 ])) [1 MEM[base: _692, index: _1412,
offset: 0B]+0 S4 A32])
        (reg:SI 7 r7 [orig:592 D.5066 ] [592])) bzip2-1.0.2/blocksort.c:564 252
{movsi_ie}
     (expr_list:REG_DEAD (reg:SI 7 r7 [orig:592 D.5066 ] [592])
        (expr_list:REG_DEAD (reg:SI 0 r0)
            (nil))))

Probably reload can't resolve adjacent insns which have r0 constraints.  I
haven't checked the details though.


Regardless of that, I think the cmpeqsi_t hunk in sh.md and the
sh_disp_addr_displacement huink in predicates.md should be applied on trunk.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 34910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34910&action=edit
Various R0 pre-alloc splits (2)

(In reply to Oleg Endo from comment #7)
> Created attachment 34902 [details]
> Various R0 pre-alloc splits
> 
> I've tried compiling CSiBE with the two split patterns in comment #5 ...
> It's a can of worms.  I'm dumping my current state as a patch here, maybe
> it's helpful in some way.  I ended up adding one r0 split pattern after
> another, but probably some are still missing.
> 
> bzip2 (haven't tried anything else so far) fails with:
> 
> internal compiler error: in spill_failure, at reload1.c:2143
> error: this is the insn:
> (insn 8965 8964 8966 70 (set (mem:SI (plus:SI (reg:SI 0 r0)
>                 (reg:SI 945 [ D.5064 ])) [1 MEM[base: _692, index: _1412,
> offset: 0B]+0 S4 A32])
>         (reg:SI 7 r7 [orig:592 D.5066 ] [592])) bzip2-1.0.2/blocksort.c:564
> 252 {movsi_ie}
>      (expr_list:REG_DEAD (reg:SI 7 r7 [orig:592 D.5066 ] [592])
>         (expr_list:REG_DEAD (reg:SI 0 r0)
>             (nil))))


The problem is this:

#define INDEX_REG_CLASS \
  (!ALLOW_INDEXED_ADDRESS ? NO_REGS : TARGET_SHMEDIA ? GENERAL_REGS : R0_REGS)

which makes reload insist on trying to put reg:SI 945 into r0, although it's
not really needed.

Changing it to '#define INDEX_REG_CLASS  GENERAL_REGS' helps.
With the attached patch bzip2 compiles.

I've taken out the save/restore move insns for r0 in the split patterns because
the trailing r0 restores create artificial/wrong r0 live ranges and trigger
further r0 spill failures down the code path.  Of course this will generate
wrong code in some situations if r0 is already live at the point, but it allows
a first code comparison.

There are code size increases.  One of the reasons is that the reg+reg mem
access patterns always force the first addr op into r0.  This is not always a
good choice.  It would be OK to do so, if there was proper address mode
selection done before RA.  

Generally, it seems reg+reg address modes are not utilized in some cases.  E.g.
this code (without the patch, trunk compiler):
.L113:
        mov.b   @r6+,r1
        dt      r3
        extu.b  r1,r1
        shll2   r1
        add     r5,r1
        mov.l   @r1,r7
        add     #1,r7
        bf/s    .L113
        mov.l   r7,@r1

should be:
        mov     r5,r0
.L113:
        mov.b   @r6+,r1
        dt      r3
        extu.b  r1,r1
        shll2   r1
        mov.l   @(r0,r1),r7
        add     #1,r7
        bf/s    .L113
        mov.l   r7,@(r0,r1)

But that's a whole different topic.
With the patched compiler the loop above gets worse:

.L113:
        mov.b    @r6+,r1
        dt    r3
        mov.w    .L187,r4    <<
        extu.b    r1,r1
        shll2    r1
        add    r15,r4      <<
        add    r4,r1
        mov.l    @r1,r7
        add    #1,r7
        bf/s    .L113
        mov.l    r7,@r1

The marked insns re-calculate the address of something on the stack inside the
loop, although that address already has been calculated before the loop.  Maybe
mem aliasing info is dropped/wrong somewhere in the split patterns, I don't
know...

At the moment, my impression is that pre-allocating r0 could work and result in
some improvements, probably even with LRA.  But it's a lot more effort than
simply adding the split patterns as in the patches.  For instance, r0 live
ranges have to be determined in order to place r0 save/restore move insns and
r0 uses should be propagated into surrounding insns to reduce the amount of
move insns to/from r0 which RA has to resolve.  Additionally, an address mode
selection pass needs to be in place which figures out how to assign index/base
regs for reg+reg mems etc.

I guess all in all this would end up being a highly specialized RA for the
single register r0.

All of that is definitely not going to help GCC 4.9 or 5.

Kaz, maybe you have an idea how to quick fix this problem?  I'm too obsessed
with the r0-prealloc idea at the moment and can't see clearly.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #9 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #8)
> Kaz, maybe you have an idea how to quick fix this problem?  I'm too obsessed
> with the r0-prealloc idea at the moment and can't see clearly.

All we have ATM are too invasive for stage4 and release branches as you
pointed out.  I think that there is no quick&safe fix.  We have already
another R0 spill issues which will be fixed with LRA.  I'm inclined
to leave these as known issues with non-LRA compilers.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #10 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
On second thought, we could fix this with an adhoc way.
I'm testing the following patch for 4.9.

diff --git a/config/sh/sh.md b/config/sh/sh.md
index d957e55..93fd84e 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -10274,7 +10202,10 @@ label:
       && GET_CODE (XVECEXP (XEXP (operands[1], 0), 0, 0)) == SYMBOL_REF
       && strcmp (XSTR (XVECEXP (XEXP (operands[1], 0), 0, 0), 0),
          "__stack_chk_guard") == 0)
-    emit_insn (gen_chk_guard_add (operands[3], operands[2]));
+    {
+      emit_barrier ();
+      emit_insn (gen_chk_guard_add (operands[3], operands[2]));
+    }
   else
     emit_move_insn (operands[3], gen_rtx_PLUS (Pmode, operands[2],
                            gen_rtx_REG (Pmode, PIC_REG)));

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #11 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Thanks!  If this successfully works around the problem, it probably would also
make sense for GCC 5 with a 'if (!sh_lra_p ()) ...'

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #12 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
It turned out that the patch in c#10 easily produces wrong codes.
Now I'm testing another adhoc fix.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #13 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 34915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34915&action=edit
an adhoc patch for 4.9

It pre-allocates R0 for this special case to break long R0 liveness.
Ugly but it works.  I'll test the similar patch on trunk with adding
!sh_lra_flag guard.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #14 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Tue Mar  3 23:51:55 2015
New Revision: 221165

URL: https://gcc.gnu.org/viewcvs?rev=221165&root=gcc&view=rev
Log:
PR target/65249
* config/sh/sh.md (symGOT_load): Use R0 reg for operands[2] when
  called for __stack_chk_guard symbol.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.md

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #15 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Tue Mar  3 23:55:24 2015
New Revision: 221166

URL: https://gcc.gnu.org/viewcvs?rev=221166&root=gcc&view=rev
Log:
PR target/65249
* config/sh/sh.md (symGOT_load): Use R0 reg for operands[2] when
  called for __stack_chk_guard symbol.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/sh/sh.md

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #16 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Mar  7 16:12:41 2015
New Revision: 221256

URL: https://gcc.gnu.org/viewcvs?rev=221256&root=gcc&view=rev
Log:
gcc/testsuite/
    PR target/65249
    * g++.dg/torture/pr65249.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr65249.C
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I think we can close this as fixed.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #18 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Reopened.  See PR66780 for details.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #19 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Although this is essentially a problem with the old reload, I'm testing
another adhoc patch which is hinted by an Oleg's patch for gbr addressing.
The problematic insn is (set (DImode R0) (DImode reg for <return value>))
originally.  The subreg lowering pass splits it to two SImode move's:
  (set (SImode R0) (SImode reg for the first word of <return value>))
  (set (SImode R1) (SImode reg for the second word of <return value>))
The ICE happens on the latter insn because R0 is live there and the source
is replaced by memory with index addressing afterwards.  The patch below
pre-splits the original DImode move in the reversed order when generating.
It also produces a bit better code for the test case even when -mlra
is specified.  I intentionally limit this pre-splitting with pseudo reg
sources.  If not, I've got some wired ICEs with too complex subreg rtl
in building gcc.  I think that almost use of R0 destination is the above
pseudo reg for <retval> source and limiting it to that case would be
not a problem.

        * config/sh/sh.md (movdi): Split simple reg move to two movsi
        when the destination is R0.

--- ../../ORIG/trunk/gcc/config/sh/sh.md        2015-07-08 10:04:22.000000000
+0900
+++ config/sh/sh.md     2015-07-13 11:09:43.028613182 +0900
@@ -7892,6 +7892,24 @@ label:
   ""
 {
   prepare_move_operands (operands, DImode);
+  if (TARGET_SH1)
+    {
+      /* When the dest operand is (R0, R1) register pair, split it to
+        two movsi of which dest is R1 and R0 so as to lower R0-register
+        pressure on the first movsi.  Apply only for simple source not
+        to make complex rtl here.  */
+      if (REG_P (operands[0])
+         && REGNO (operands[0]) == R0_REG
+         && REG_P (operands[1])
+         && REGNO (operands[1]) >= FIRST_PSEUDO_REGISTER)
+       {
+         emit_insn (gen_movsi (gen_rtx_REG (SImode, R1_REG),
+                               gen_rtx_SUBREG (SImode, operands[1], 4)));
+         emit_insn (gen_movsi (gen_rtx_REG (SImode, R0_REG),
+                               gen_rtx_SUBREG (SImode, operands[1], 0)));
+         DONE;
+       }
+    }
 })

 (define_insn "movdf_media"

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #20 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #19)

Just for my understanding ... at which time does the modified expand pattern
kick in?  Before RA, during RA or after RA?  It's a bit confusing, because
operands[0] is already a hard-reg and operands[1] is supposed to be a pseudo
...

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #21 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #20)
> Just for my understanding ... at which time does the modified expand pattern
> kick in?  Before RA, during RA or after RA?  It's a bit confusing, because
> operands[0] is already a hard-reg and operands[1] is supposed to be a pseudo
> ...

Before RA, during expand phase.  It's generated by function.c:
expand_function_end with
 emit_move_insn (crtl->return_rtx,
                 DECL_RTL (DECL_RESULT (current_function_decl))
essentially.  In this case, crtl->return_rtx is (reg/i:DI 0 r0).

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #22 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #21)
> Before RA, during expand phase.  It's generated by function.c:
> expand_function_end with
>  emit_move_insn (crtl->return_rtx,
> 	         DECL_RTL (DECL_RESULT (current_function_decl))
> essentially.  In this case, crtl->return_rtx is (reg/i:DI 0 r0).

Ah, I see.  Thanks.
>From gcc-bugs-return-492341-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 15 13:31:32 2015
Return-Path: <gcc-bugs-return-492341-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26187 invoked by alias); 15 Jul 2015 13:31:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26130 invoked by uid 48); 15 Jul 2015 13:31:27 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66878] Segmentation fault when compiling
Date: Wed, 15 Jul 2015 13:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66878-4-R2vu2Z5bBC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66878-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66878-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01231.txt.bz2
Content-length: 189

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf878

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This is infinite recursion in push_inner_scope_r -> stack overflow.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #23 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Thu Jul 16 00:48:33 2015
New Revision: 225856

URL: https://gcc.gnu.org/viewcvs?rev=225856&root=gcc&view=rev
Log:
PR target/65249
* config/sh/sh.md (movdi): Split simple reg move to two movsi when
  the destination is R0 so as to lower R0-register pressure.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.md

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #24 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Sat Jul 25 01:24:27 2015
New Revision: 226200

URL: https://gcc.gnu.org/viewcvs?rev=226200&root=gcc&view=rev
Log:
PR target/65249
* config/sh/sh.md (movdi): Split simple reg move to two movsi when
  the destination is R0 so as to lower R0-register pressure.


Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/sh/sh.md

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

--- Comment #25 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Sat Jul 25 01:26:55 2015
New Revision: 226201

URL: https://gcc.gnu.org/viewcvs?rev=226201&root=gcc&view=rev
Log:
PR target/65249
* config/sh/sh.md (movdi): Split simple reg move to two movsi when
  the destination is R0 so as to lower R0-register pressure.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/sh/sh.md

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #26 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Fixed.