[Bug target/22553] [4.3/4.4/4.5/4.6/4.7 regression] ICE building libstdc++

[Bug target/22553] [4.3/4.4/4.5/4.6/4.7 regression] ICE building libstdc++

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.6                       |4.4.7

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-27 12:14:40 UTC ---
4.3 branch is being closed, moving to 4.4.7 target.

[Bug target/22553] [4.4/4.5/4.6/4.7 regression] ICE building libstdc++

[belyshev at depni dot sinp.msu.ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #19 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> 2011-11-08 09:10:22 UTC ---
Note that both original testcase and its fully reduced variants are flakey, so
one needs to check against all intermediate ones generated by delta.

Anyway, with the workaround from r105496 reverted, this bug no longer appears
since r122318:

2007-02-25  Ulrich Weigand  <uweigand@de.ibm.com>

        * reload.c (find_reloads_address_1): Handle PLUS expressions resulting
        from register elimination as PRE_MODIFY / POST_MODIFY increments.
        Do not attempt to handle MEM inside auto-inc expressions.
        * reload1.c (eliminate_regs_1): Do not attempt to handle elimination
        of a register modified by an auto-inc expression.  However, do handle
        elimination of a register used as PRE_MODIFY / POST_MODIFY increment.
        (elimination_effects): Prohibit elimination of a register modified
        by an auto-inc expression.  Disable register elimination rules whose
        target register is modified by an auto-inc expression with variable
        increment.

Which looks like real fix for the issue.
Another big change that can also help here is -fsched-pressure in r151348:

2009-09-02  Vladimir Makarov  <vmakarov@redhat.com>

        * doc/invoke.texi (-fsched-pressure): Document it.
        (-fsched-reg-pressure-heuristic): Remove it.
        ...

So I think the workaround from r105496 can be safely removed now and then close
this bug as fixed since 4.3.0

[Bug target/22553] [4.4/4.5/4.6/4.7 regression] ICE building libstdc++

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #20 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-11-09 14:07:01 UTC ---
(In reply to comment #19)
> So I think the workaround from r105496 can be safely removed now and then close
> this bug as fixed since 4.3.0

I've confirmed that there are no ICEs on SH with reverting
105496 change, though I can't get why does the change pointed
in #19 fix the issue pointed by Joern with
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01654.html

[Bug target/22553] [4.5/4.6/4.7/4.8 regression] ICE building libstdc++

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:48:12 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #22 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-07-18 20:12:22 UTC ---
On 'gcc version 4.8.0 20120718 (experimental)' I've commented out the
'if (targetm.small_register_classes_for_mode_p (VOIDmode))' block in sh.c
(sh_option_override) and ran some CSiBE result-size tests.

There is a total increase of +19746 bytes / +0.624419, but there are also some
individual decreases.
I've briefly compared some of the compiled files and it seems that with
-fschedule-insn enabled the interleaving of LS/MT/EX group instructions seems
to be a bit better, although I don't have any runtime numbers.

Kaz, if you have some time, could you do something like that
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01539.html
again (if possible with mpeg2dec) with GCC 4.8?

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #23 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2012-07-19 02:36:19 UTC ---
(In reply to comment #22)
> Kaz, if you have some time, could you do something like that
> http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01539.html
> again (if possible with mpeg2dec) with GCC 4.8?

Here is:

(CSiBE with -O2)
test name            sched1     no-sched1     sched1/no-sched1

bzip2-1.0.2 bzip2.d        11.06     10.8067     1.02344
bzip2-1.0.2 bzip2recover    4.54333     4.66333     0.974267
bzip2-1.0.2 bzip2.c        42.8567     44.2067     0.969462
compiler vam.fib        2.00333     1.97         1.01692
compiler vam.fact        1.87333     1.88333     0.99469
compiler vam.test2        0.246667 0.25         0.986667
flex-2.5.31 flex        13.1133     13.25         0.989686
jikespg-1.3 src/jikespg        1.62     1.59333     1.01674
jpeg-6b jpegtran2        4.62667     4.74667     0.974719
jpeg-6b djpeg2            2.19333     2.28667     0.960641
jpeg-6b djpeg1            2.2     2.26667     0.970588
jpeg-6b cjpeg2            3.19333     3.05333     1.04585
jpeg-6b djpeg0            0.33     0.33         1
jpeg-6b cjpeg0            0.496667 0.496667     1
jpeg-6b cjpeg1            3.18     3.11667     1.02032
jpeg-6b jpegtran0        0.256667 0.256667     1
jpeg-6b jpegtran1        1.98667     2.00667     0.990033
libpng-1.2.5 png2pnm0        0.973333 0.97         1.00344
libpng-1.2.5 pnm2png1        44.63     44.6933     0.998583
libpng-1.2.5 pnm2png0        7.94667     7.95         0.999581
libpng-1.2.5 png2pnm1        6.71667     6.71         1.00099
teem-1.6.0-src src/hex/dehex0    1.66     1.68         0.988095
teem-1.6.0-src src/hex/dehex1    10.8967     10.92         0.997863
teem-1.6.0-src src/hex/enhex1    40.5033     41.2133     0.982773
teem-1.6.0-src src/hex/enhex0    6.76333     6.86667     0.984951
zlib-1.1.4 minigzip0        44.73     45.0633     0.992603
zlib-1.1.4 minigzip        5.41333     5.41333     1

(not CSiBE test with -O3. 201 frames decoded)
mpeg2dec-0.3.1            2.18     2.22         0.981981

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #24 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2012-07-19 04:58:46 UTC ---
With -fPIC

(CSiBE with -O2 -fPIC)
test name            sched1     no-sched1     sched1/no-sched1

bzip2-1.0.2 bzip2.d         11.1433  11.1833      0.996423
bzip2-1.0.2 bzip2recover     5.15333  5.14667      1.0013
bzip2-1.0.2 bzip2.c         43.3033  43.61          0.992968
compiler vam.fib         1.99333  2          0.996667
compiler vam.fact         1.87667  1.89667      0.989455
compiler vam.test2         0.266667 0.263333      1.01266
flex-2.5.31 flex         15.3      15.3          1
jikespg-1.3 src/jikespg     1.68      1.66667      1.008
jpeg-6b jpegtran2         4.76      4.76333      0.9993
jpeg-6b djpeg2             2.41333  2.43          0.993141
jpeg-6b djpeg1             2.37333  2.36333      1.00423
jpeg-6b cjpeg2             3.01333  3.05333      0.9869
jpeg-6b djpeg0             0.35      0.323333      1.08247
jpeg-6b cjpeg0             0.496667 0.476667      1.04196
jpeg-6b cjpeg1             3.08      3.07          1.00326
jpeg-6b jpegtran0         0.256667 0.266667      0.9625
jpeg-6b jpegtran1         1.94333  1.95333      0.994881
libpng-1.2.5 png2pnm0         0.98      0.97          1.01031
libpng-1.2.5 pnm2png1         45      44.9667      1.00074
libpng-1.2.5 pnm2png0         7.99      7.99333      0.999583
libpng-1.2.5 png2pnm1         6.74333  6.78333      0.994103
teem-1.6.0-src src/hex/dehex0     1.69      1.67333      1.00996
teem-1.6.0-src src/hex/dehex1     11.0433  11.01          1.00303
teem-1.6.0-src src/hex/enhex1     41.0633  40.5333      1.01308
teem-1.6.0-src src/hex/enhex0     6.25667  6.24          1.00267
zlib-1.1.4 minigzip0         44.1267  44.1467      0.999547
zlib-1.1.4 minigzip         5.30667  5.30333      1.00063

(not CSiBE test with -O3 -fPIC. 201 frames decoded)

mpeg2dec-0.3.1            2.27     2.27         1

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrbr at gcc dot gnu.org

--- Comment #25 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-07-22 15:25:05 UTC ---
Thanks for the numbers!
Although, on average, it doesn't seem to be worth it to enable sched1, it seems
to 'fix' PR 11261.

Christian, do you have any experience with enabling -fschedule-insns?

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #26 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-09 21:44:16 UTC ---
I've tried enabling sched1 on rev 193341 and ran the test suite with
make -k -j4 check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

I got one failure for -m2a, -m4 -m4a (both, -ml and -mb):

FAIL: gcc.dg/pr42475.c (internal compiler error)

The error is:
sh_tmp.cpp: In function 'baz':
sh_tmp.cpp:25:1: error: unable to find a register to spill in class 'R0_REGS'
 }
 ^
sh_tmp.cpp:25:1: error: this is the insn:
(insn 18 31 42 2 (parallel [
            (set (subreg:SF (reg:SI 1 r1 [orig:174 D.1383+4 ] [174]) 0)
                (mult:SF (reg:SF 171)
                    (reg:SF 65 fr1 [orig:170 p.c.z ] [170])))
            (use (reg/v:PSI 151 ))
        ]) sh_tmp.cpp:24 426 {mulsf3_i}
     (expr_list:REG_DEAD (reg:SF 171)
        (expr_list:REG_DEAD (reg:SF 65 fr1 [orig:170 p.c.z ] [170])
            (expr_list:REG_DEAD (reg/v:PSI 151 )
                (nil)))))
sh_tmp.cpp:25:1: internal compiler error: in spill_failure, at reload1.c:2124

A GP reg is supposed to receive the result of an FP operation, which the SH
actually can't do.  It has to go through FPUL.
The error occurs because sched1 hoists a load of r0 (part of the return value)
before the failing insn:

(insn 31 15 18 2 (set (reg:SI 0 r0)
        (const_int 0 [0])) sh_tmp.cpp:25 244 {movsi_ie}
     (nil))
(insn 18 31 42 2 (parallel [
            (set (subreg:SF (reg:SI 174 [ D.1383+4 ]) 0)
                (mult:SF (reg:SF 170 [ p.c.z ])
                    (reg:SF 171)))
....

The result value transfer from FP reg to GP reg (through FPUL) seems to go a
long way during reload, and one the insns that reload checks has a R0 clobber
(not sure which one, but there are a couple of reload insns with a =&z
constraint).

On option to fix this is to split such insns.  The patch below fixes the test
case failure, but I haven't re-tested it completely.


Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md    (revision 193342)
+++ gcc/config/sh/sh.md    (working copy)
@@ -12077,6 +12077,32 @@
   [(set_attr "type" "fp")
    (set_attr "fp_mode" "single")])

+;; If the output of a floating-point operation is to be stored in a GP reg
+;; the target GP output reg might be propagated as a subreg into floating-
+;; point insns.  If we split the operation and the GP reg store
+;; (through FPUL) into separate insns before reload some trouble can be
+;; avoided during reload.
+(define_split
+  [(set (match_operand:SF 0 "fp_arith_reg_operand")
+    (match_operator:SF 1 "float_operator"
+      [(match_operand:SF 2 "fp_arith_reg_operand")
+       (match_operand:SF 3 "fp_arith_reg_operand")]))
+   (use (match_operand:PSI 4 "fpscr_operand"))]
+  "TARGET_SH2E
+   && can_create_pseudo_p () && GET_CODE (operands[0]) == SUBREG
+   && REG_P (SUBREG_REG (operands[0]))
+   && GET_MODE (SUBREG_REG (operands[0])) != SFmode"
+  [(parallel [(set (match_dup 5) (match_dup 6))
+          (use (match_dup 4))])
+   (parallel [(set (match_dup 0) (match_dup 5))
+          (use (match_dup 4))
+          (clobber (reg:SI FPUL_REG))])]
+{
+  operands[5] = gen_reg_rtx (SFmode);
+  operands[6] = gen_rtx_fmt_ee (GET_CODE (operands[1]), SFmode, operands[2],
+                operands[3]);
+})
+
 ;; FMA (fused multiply-add) patterns
 (define_expand "fmasf4"
   [(set (match_operand:SF 0 "fp_arith_reg_operand" "")
Index: gcc/config/sh/predicates.md
===================================================================
--- gcc/config/sh/predicates.md    (revision 193342)
+++ gcc/config/sh/predicates.md    (working copy)
@@ -1156,3 +1156,9 @@

   return false;
 })
+
+(define_predicate "float_operator"
+  (ior (match_operand 0 "binary_float_operator")
+       (match_operand 0 "commutative_float_operator")
+       (match_operand 0 "noncommutative_float_operator")
+       (match_operand 0 "unary_float_operator")))
Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c    (revision 193342)
+++ gcc/config/sh/sh.c    (working copy)
@@ -877,6 +877,7 @@
       || (TARGET_SHMEDIA && !TARGET_PT_FIXED))
     flag_no_function_cse = 1;

+#if 0
   if (targetm.small_register_classes_for_mode_p (VOIDmode))        \
     {
       /* Never run scheduling before reload, since that can
@@ -903,6 +904,7 @@
            && !global_options_set.x_flag_schedule_insns)
     flag_schedule_insns = 0;
     }
+#endif

   /* Unwind info is not correct around the CFG unless either a frame
      pointer is present or M_A_O_A is set.  Fixing this requires rewriting

[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

--- Comment #27 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-09 22:41:15 UTC ---
(In reply to comment #26)

Another way that fixes the problem mentioned above is to not allow non-float
mode operands in the first place.  The patch below also fixes the failure, but
requires some more work to be complete.
A strange thing I've noticed:

(define_expand "addsf3"
  [(set (match_operand:SF 0 "arith_reg_operand" "")
    (plus:SF (match_operand:SF 1 "arith_reg_operand" "")
         (match_operand:SF 2 "arith_reg_operand" "")))]
  "TARGET_SH2E || TARGET_SHMEDIA_FPU"

It seems there should be a prefix "fp_" in the operand predicate names.
Anyway .. 

Index: gcc/config/sh/predicates.md
===================================================================
--- gcc/config/sh/predicates.md    (revision 193342)
+++ gcc/config/sh/predicates.md    (working copy)
@@ -319,16 +319,23 @@
   if (register_operand (op, mode))
     {
       int regno;
+      machine_mode m;

       if (REG_P (op))
-    regno = REGNO (op);
+    {
+      regno = REGNO (op);
+      m = GET_MODE (op);
+    }
       else if (GET_CODE (op) == SUBREG && REG_P (SUBREG_REG (op)))
-    regno = REGNO (SUBREG_REG (op));
+    {
+      regno = REGNO (SUBREG_REG (op));
+      m = GET_MODE (SUBREG_REG (op));
+    }
       else
     return 1;

-      return (regno >= FIRST_PSEUDO_REGISTER
-          || FP_REGISTER_P (regno));
+      return (regno >= FIRST_PSEUDO_REGISTER || FP_REGISTER_P (regno))
+         && GET_MODE_CLASS (m) == MODE_FLOAT;
     }
   return 0;
 })
Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c    (revision 193342)
+++ gcc/config/sh/sh.c    (working copy)
@@ -876,7 +876,7 @@
   if ((flag_pic && ! TARGET_PREFERGOT)
       || (TARGET_SHMEDIA && !TARGET_PT_FIXED))
     flag_no_function_cse = 1;
-
+#if 0
   if (targetm.small_register_classes_for_mode_p (VOIDmode))        \
     {
       /* Never run scheduling before reload, since that can
@@ -903,6 +903,7 @@
            && !global_options_set.x_flag_schedule_insns)
     flag_schedule_insns = 0;
     }
+#endif

   /* Unwind info is not correct around the CFG unless either a frame
      pointer is present or M_A_O_A is set.  Fixing this requires rewriting
@@ -10069,6 +10070,9 @@
 void
 expand_sf_binop (rtx (*fun) (rtx, rtx, rtx, rtx), rtx *operands)
 {
+  operands[0] = force_reg (SFmode, operands[0]);
+  operands[1] = force_reg (SFmode, operands[1]);
+  operands[2] = force_reg (SFmode, operands[2]);
   emit_sf_insn ((*fun) (operands[0], operands[1], operands[2],
              get_fpscr_rtx ()));
 }

[Bug target/22553] [4.7/4.8/4.9 regression] ICE building libstdc++

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:17:07 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug target/22553] [4.7/4.8/4.9 regression] ICE building libstdc++

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |FIXED

--- Comment #29 from Jeffrey A. Law <law at redhat dot com> ---
Fixed eons ago based on c#19 & c#20.  Comments after that are only marginally
related as they're reports on some experimental work.