[Bug middle-end/59049] New: Two VOIDmode constant in comparison passed to cstoresi4

[Bug middle-end/59049] New: Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

            Bug ID: 59049
           Summary: Two VOIDmode constant in comparison passed to
                    cstoresi4
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amylaar at gcc dot gnu.org

For gcc.c-torture/execute/builtins/strlen-2.c compilation,  -O1, with
target arc-elf, I see an ICE in config/arc/arc.c:gen_compare_reg,
as it has been passed a comparison for two VOIDmode constants:

(ne:SI (const_int 3 [0x3])
     (const_int 3 [0x3]))

We should not generate such comparisons.

[amylaar@rowan gcc]$ ./cc1 -fpreprocessed strlen-2.i -quiet -dumpbase
strlen-2.c -auxbase strlen-2 -O1 -w -version -fno-diagnostics-show-caret
-fdiagnostics-color=never -fno-tree-loop-distribute-patterns -o strlen-2.s
GNU C (GCC) version 4.9.0 20131024 (experimental) (arc-elf)
        compiled by GNU C version 4.8.1 20130603 (Red Hat 4.8.1-1), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20131024 (experimental) (arc-elf)
        compiled by GNU C version 4.8.1 20130603 (Red Hat 4.8.1-1), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a28c59382a8f5b3c721a450c1591fc5d
/home/amylaar/synopsys/synopsys-gcc-mainline/unisrc-4.8/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c:
In function ‘main_test’:
/home/amylaar/synopsys/synopsys-gcc-mainline/unisrc-4.8/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c:25:1:
internal compiler error: in gen_compare_reg, at config/arc/arc.c:1430
0x899316f gen_compare_reg(rtx_def*, machine_mode)
        ../../gcc/gcc/config/arc/arc.c:1430
0x89cfa80 gen_cstoresi4(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
        ../../gcc/gcc/config/arc/arc.md:3208
0x85c8a6d insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
        ../../gcc/gcc/recog.h:286
0x85c83b9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
        ../../gcc/gcc/optabs.c:8217
0x85c8604 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
        ../../gcc/gcc/optabs.c:8243
0x83942ef emit_cstore
        ../../gcc/gcc/expmed.c:5121
0x8394a85 emit_store_flag_1
        ../../gcc/gcc/expmed.c:5362
0x8394b7c emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
        ../../gcc/gcc/expmed.c:5405
0x83959ec emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
        ../../gcc/gcc/expmed.c:5727
0x83ba5dd do_store_flag
        ../../gcc/gcc/expr.c:10832
0x83b1fb5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../gcc/gcc/expr.c:8787
0x83b9191 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
        ../../gcc/gcc/expr.c:10444
0x83ad831 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**)
        ../../gcc/gcc/expr.c:7796
0x83b3ab6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
        ../../gcc/gcc/expr.c:9253
0x83ad831 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**)
        ../../gcc/gcc/expr.c:7796
0x831e807 expand_normal
        ../../gcc/gcc/expr.h:450
0x8320856 do_jump(tree_node*, rtx_def*, rtx_def*, int)
        ../../gcc/gcc/dojump.c:608
0x831fa22 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*, int)
        ../../gcc/gcc/dojump.c:364
0x831e918 jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int)
        ../../gcc/gcc/dojump.c:114
0x82af4bd expand_gimple_cond
        ../../gcc/gcc/cfgexpand.c:2030
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

emit_cstore has generated this comparison.  I propose to use copy_to_mode_reg
in this case to preserve the information about the mode.
I see that for the testcase, the unnecessary instructions are removed in
the ce1 pass.
>From gcc-bugs-return-433938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 08 13:21:04 2013
Return-Path: <gcc-bugs-return-433938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25746 invoked by alias); 8 Nov 2013 13:21:04 -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 25728 invoked by uid 48); 8 Nov 2013 13:21:01 -0000
From: "octoploid at yandex dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59050] New: [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
Date: Fri, 08 Nov 2013 13:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: octoploid at yandex dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59050-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00715.txt.bz2
Content-length: 2369

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

            Bug ID: 59050
           Summary: [4.9 Regression] ICE: tree check: expected
                    integer_cst, have nop_expr in tree_int_cst_lt, at
                    tree.c:7083
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: octoploid at yandex dot com

markus@x4 tsan % cat test.ii
struct {
  int trace[6];
} a;
void fn1() {
  for (int i; i; i++) {
    a.trace[i] = a.trace[-i];
    a.trace[-i] = 0;
  }
}

markus@x4 tsan % /var/tmp/gcc_build_dir/./gcc/xgcc
-B/var/tmp/gcc_build_dir/./gcc -O3 test.ii
test.ii:3:3: warning: anonymous type with no linkage used to declare variable
‘<anonymous struct> a’ with linkage [enabled by default]
 } a;
   ^
test.ii: In function ‘void fn1()’:
test.ii:4:6: internal compiler error: tree check: expected integer_cst, have
nop_expr in tree_int_cst_lt, at tree.c:7083
 void fn1() {
      ^
0xd1c3f4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
        ../../gcc/gcc/tree.c:9477
0xd1e354 tree_check
        ../../gcc/gcc/tree.h:2914
0xd1e354 tree_int_cst_lt(tree_node const*, tree_node const*)
        ../../gcc/gcc/tree.c:7083
0xd1e390 tree_int_cst_compare(tree_node const*, tree_node const*)
        ../../gcc/gcc/tree.c:7093
0x100228c comp_dr_addr_with_seg_len_pair
        ../../gcc/gcc/tree-vect-data-refs.c:2672
0x100af25 vec<dr_addr_with_seg_len_pair_t, va_heap, vl_embed>::qsort(int
(*)(void const*, void const*))
        ../../gcc/gcc/vec.h:941
0x100af25 vec<dr_addr_with_seg_len_pair_t, va_heap, vl_ptr>::qsort(int (*)(void
const*, void const*))
        ../../gcc/gcc/vec.h:1620
0x100af25 vect_prune_runtime_alias_test_list(_loop_vec_info*)
        ../../gcc/gcc/tree-vect-data-refs.c:2845
0xce76f2 vect_analyze_loop_2
        ../../gcc/gcc/tree-vect-loop.c:1716
0xce76f2 vect_analyze_loop(loop*)
        ../../gcc/gcc/tree-vect-loop.c:1807
0xcfdaff vectorize_loops()
        ../../gcc/gcc/tree-vectorizer.c:360
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-433939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 08 13:34:46 2013
Return-Path: <gcc-bugs-return-433939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5589 invoked by alias); 8 Nov 2013 13:34:46 -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 5569 invoked by uid 48); 8 Nov 2013 13:34:43 -0000
From: "jsm28 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/59051] New: DW_tag_restrict_type not used
Date: Fri, 08 Nov 2013 13:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59051-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: 2013-11/txt/msg00716.txt.bz2
Content-length: 490

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY051

            Bug ID: 59051
           Summary: DW_tag_restrict_type not used
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jsm28 at gcc dot gnu.org

GCC should use DW_tag_restrict_type in debug info when describing the types of
restrict-qualified pointers.

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu.org,
                   |                            |steven at gcc dot gnu.org

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
The regression shows up at r204194 :
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204194

The 104t.copyprop6 looks indeed more cumbersome for r204194 than for r204193:

--- ../204193/strlen-2.i.104t.copyprop6 2013-11-08 16:03:58.272739028 +0000
+++ ./strlen-2.i.104t.copyprop6 2013-11-08 16:04:18.355773658 +0000
@@ -27,11 +27,15 @@

 main_test ()
 {
+  char[4] * iftmp.2_1;
+  const char * iftmp.6_2;
   const char * iftmp.12_3;
   long unsigned int g.3_7;
   long unsigned int g.5_8;
+  long unsigned int _10;
   long unsigned int h.7_11;
   long unsigned int h.9_12;
+  long unsigned int _14;
   long unsigned int i.10_15;
   long unsigned int i.11_16;
   long unsigned int j.13_19;
@@ -44,24 +48,31 @@
   long unsigned int _28;
   long unsigned int k.14_29;
   long unsigned int l.20_33;
+  _Bool _34;
+  _Bool _35;
+  _Bool _36;
+  _Bool _37;
+  _Bool _38;
+  _Bool _39;

   <bb 2>:
   g.3_7 = g;
   g.5_8 = g.3_7 + 1;
   g = g.5_8;
-  if (g.5_8 != 1)
+  if (g.3_7 != 0)
     goto <bb 3>;
   else
     goto <bb 4>;

   <bb 3>:
-  abort ();

   <bb 4>:
-  h.7_11 = h;
-  h.9_12 = h.7_11 + 1;
-  h = h.9_12;
-  if (h.9_12 != 1)
+  # iftmp.2_1 = PHI <"foo"(3), "bar"(2)>
+  _10 = strlen (iftmp.2_1);
+  _34 = g.5_8 != 1;
+  _35 = _10 != 3;
+  _36 = _35 | _34;
+  if (_36 != 0)
     goto <bb 5>;
   else
     goto <bb 6>;
@@ -70,68 +81,93 @@
   abort ();

   <bb 6>:
+  h.7_11 = h;
+  h.9_12 = h.7_11 + 1;
+  h = h.9_12;
+  if (h.7_11 != 0)
+    goto <bb 7>;
+  else
+    goto <bb 8>;
+
+  <bb 7>:
+
+  <bb 8>:
+  # iftmp.6_2 = PHI <&MEM[(void *)"xfoo" + 1B](7), "bar"(6)>
+  _14 = strlen (iftmp.6_2);
+  _37 = h.9_12 != 1;
+  _38 = _14 != 3;
+  _39 = _38 | _37;
+  if (_39 != 0)
+    goto <bb 9>;
+  else
+    goto <bb 10>;
+
+  <bb 9>:
+  abort ();
+
+  <bb 10>:
   i.10_15 = i;
   i.11_16 = i.10_15 + 1;
   i = i.11_16;
   if (i.11_16 != 1)
-    goto <bb 7>;
+    goto <bb 11>;
   else
-    goto <bb 8>;
+    goto <bb 12>;

-  <bb 7>:
+  <bb 11>:
   abort ();

-  <bb 8>:
+  <bb 12>:
   inside_main = 0;
   j.13_19 = j;
   if (j.13_19 != 0)
-    goto <bb 9>;
+    goto <bb 13>;
   else
-    goto <bb 10>;
+    goto <bb 14>;

-  <bb 9>:
+  <bb 13>:
   k.14_20 = k;
   k.16_21 = k.14_20 + 1;
   k = k.16_21;
   iftmp.12_23 = "foo" + k.14_20;
-  goto <bb 11>;
+  goto <bb 15>;

-  <bb 10>:
+  <bb 14>:
   k.14_24 = k;
   k.18_25 = k.14_24 + 1;
   k = k.18_25;
   iftmp.12_27 = "bar" + k.14_24;

-  <bb 11>:
-  # iftmp.12_3 = PHI <iftmp.12_23(9), iftmp.12_27(10)>
+  <bb 15>:
+  # iftmp.12_3 = PHI <iftmp.12_23(13), iftmp.12_27(14)>
   _28 = strlen (iftmp.12_3);
   if (_28 != 3)
-    goto <bb 13>;
+    goto <bb 17>;
   else
-    goto <bb 12>;
+    goto <bb 16>;

-  <bb 12>:
+  <bb 16>:
   k.14_29 = k;
   if (k.14_29 != 1)
-    goto <bb 13>;
+    goto <bb 17>;
   else
-    goto <bb 14>;
+    goto <bb 18>;

-  <bb 13>:
+  <bb 17>:
   abort ();

-  <bb 14>:
+  <bb 18>:
   foo ();
   l.20_33 = l;
   if (l.20_33 != 1)
-    goto <bb 15>;
+    goto <bb 19>;
   else
-    goto <bb 16>;
+    goto <bb 20>;

-  <bb 15>:
+  <bb 19>:
   abort ();

-  <bb 16>:
+  <bb 20>:
   return;

 }

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

--- Comment #3 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
Making emit_store_flag return 0 in the case of const-const comparison
gives simpler rtl generation:

(insn 14 13 15 (set (reg:QI 175)
        (const_int 1 [0x1])) .../strlen-2.c:29 -1
     (nil))

(insn 15 14 16 (set (reg:QI 175)
        (const_int 0 [0])) .../strlen-2.c:29 -1
     (nil))

(code_label 16 15 0 8 "" [0 uses])

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
We do have a missed optimization due to fab being done so late.

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
A patch is here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00931.html

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have

  <bb 4>:
  # iftmp.2_1 = PHI <"foo"(2), "bar"(3)>
  _10 = 3;
  _34 = g.5_8 != 1;
  _35 = _10 != 3;

in .optimized, as fold-all-builtins manages to produce that from

  <bb 4>:
  # iftmp.2_1 = PHI <"foo"(3), "bar"(2)>
  _10 = strlen (iftmp.2_1);
  _34 = g.5_8 != 1;
  _35 = _10 != 3;

we don't re-fold the strlen call earlier as it doesn't change (only the
PHI node feeding it does!).  The fact that we don't propagate string-lengths
separately in CCP makes this a somewhat ill-fit for handling during the
CCP propagation stage.

At -O2 jump threading and the strlen pass handle it well.

So indeed an oddity - probably TER simply should not forward constants
to not confuse RTL expansion.

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
That is, sth like

Index: gcc/tree-ssa-ter.c
===================================================================
--- gcc/tree-ssa-ter.c  (revision 204664)
+++ gcc/tree-ssa-ter.c  (working copy)
@@ -438,6 +439,12 @@ ter_is_replaceable_p (gimple stmt)
          && !is_gimple_val (gimple_assign_rhs1 (stmt)))
        return false;

+      /* Do not propagate "modeless" constants - we may end up confusing the
RTL
+        expanders.  Leave the optimization to RTL CCP.  */
+      if (gimple_assign_single_p (stmt)
+         && CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt)))
+       return false;
+
       return true;
     }
   return false;

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

--- Comment #8 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> That is, sth like
> 
> Index: gcc/tree-ssa-ter.c
> ===================================================================
> --- gcc/tree-ssa-ter.c  (revision 204664)
> +++ gcc/tree-ssa-ter.c  (working copy)
> @@ -438,6 +439,12 @@ ter_is_replaceable_p (gimple stmt)
>           && !is_gimple_val (gimple_assign_rhs1 (stmt)))
>         return false;
>  
> +      /* Do not propagate "modeless" constants - we may end up confusing
> the RTL
> +        expanders.  Leave the optimization to RTL CCP.  */
> +      if (gimple_assign_single_p (stmt)
> +         && CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt)))
> +       return false;
> +
>        return true;
>      }
>    return false;

Constants are often very valuable for rtl expansion, allowing to use
cheaper patterns.
And some constant propagations are impossible in rtl because of mode
oddities.  E.g. when you have a have a mulsidi3 pattern, you generally
have a sign_extend - you can't have a VOIDmode constant inside that.
Therefore, I would rather have the middle-end move the constants
to registers only when necessary to preserve the mode, and preferrably
fold instead in the first place when optimizing.

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

--- Comment #9 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
Author: amylaar
Date: Mon Nov 11 18:57:25 2013
New Revision: 204682

URL: http://gcc.gnu.org/viewcvs?rev=204682&root=gcc&view=rev
Log:
        PR middle-end/59049
        * expmed.c (emit_store_flag): Fail for const-const comparison.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c

[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

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

--- Comment #10 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
Problem has been fixed for 4.9 with the commit shown in comment #9.