[Bug middle-end/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

2020-02-14 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
Note that the pattern will get sign of floating-point zero wrong if it ever
triggers for an fp type.

Also, it's too specific: it at least misses eq/ne comparisons, but generally
speaking it doesn't need to be tied to comparisons in the first place: any
multiplication by a boolean value can be converted to a select.

[Bug middle-end/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

2020-02-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #3 from Jakub Jelinek  ---
Well, genmatch has some code to add TREE_SIDE_EFFECTS checks on its own, but
apparently it doesn't trigger in this case, perhaps it needs be conditional in
the matching pattern rather than replacement or it needs to be matched more
than once.
--- gcc/match.pd.jj 2020-02-05 11:12:33.679383217 +0100
+++ gcc/match.pd2020-02-14 22:31:46.416421704 +0100
@@ -1472,7 +1472,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for cmp (gt lt ge le)
 (simplify
  (mult (convert (cmp @0 @1)) @2)
-  (cond (cmp @0 @1) @2 { build_zero_cst (type); })))
+  (if (GIMPLE || !TREE_SIDE_EFFECTS (@2))
+   (cond (cmp @0 @1) @2 { build_zero_cst (type); }

 /* For integral types with undefined overflow and C != 0 fold
x * C EQ/NE y * C into x EQ/NE y.  */
of course fixes it, will bootstrap/regtest it with the testcase and let's see
what Richi will say ;).

[Bug middle-end/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

2020-02-14 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #2 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #1)
> Started with r8-2090-g2071f8f980cc0de02af3d7d7de201f4f189058ff
I was thinking it was that and I was looking for that part in match.pd earlier.
 There are two ways of fixing this I can see; checking for side effects or just
having this pattern only for GIMPLE.

[Bug middle-end/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

2020-02-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|9.3 |8.4
Summary|[9/10 Regression] Different |[8/9/10 Regression]
   |results between gcc-9 and   |Different results between
   |gcc-7   |gcc-9 and gcc-7

--- Comment #1 from Jakub Jelinek  ---
Started with r8-2090-g2071f8f980cc0de02af3d7d7de201f4f189058ff
typedef int I;

int
main ()
{
  int a = 0;
  I b = 0;
  (a > 0) * (b |= 2);
  if (b != 2)
__builtin_abort ();
  return 0;
}

[Bug middle-end/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

2020-02-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-14
 Ever confirmed|0   |1