[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-22 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
*** Bug 69430 has been marked as a duplicate of this bug. ***

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-22 Thread rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #9 from Richard Henderson  ---
Author: rth
Date: Fri Jan 22 17:21:41 2016
New Revision: 232737

URL: https://gcc.gnu.org/viewcvs?rev=232737=gcc=rev
Log:
PR target/69416

  * config/aarch64/aarch64.md (UNSPEC_NZCV): New.
  (ccmp, fccmp, fccmpe): Use it.

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

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-21
 CC||ktkachov at gcc dot gnu.org,
   ||wdijkstr at arm dot com
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

Richard Henderson  changed:

   What|Removed |Added

   Keywords||build, ice-checking,
   ||wrong-code
 Target|aarch64 |aarch64-*
   Priority|P3  |P1
   Host||aarch64-*
   Target Milestone|--- |6.0
  Build||aarch64-*

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #2 from Wilco  ---
Started looking at this- it looks like line 1833 in emit-rtl.c gets miscompiled
in combine:

(insn 397 389 394 38 (set (reg:SI 462)
(const_int 29 [0x1d])) ./emit-rtl.c:1833 49 {*movsi_aarch64}
 (nil))
(insn 394 397 399 38 (set (reg:CC 66 cc)
(compare:CC (reg:SI 1002 [ ref_309(D)->code ])
(const_int 47 [0x2f]))) ./emit-rtl.c:1833 385 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 1002 [ ref_309(D)->code ])
(nil)))
(insn 399 394 400 38 (set (reg:CC 66 cc)
(if_then_else:CC (ne (reg:CC 66 cc)
(const_int 0 [0]))
(compare:CC (reg:SI 462)
(const_int 1 [0x1]))
(const_int 8 [0x8]))) ./emit-rtl.c:1833 3 {ccmpsi}
 (expr_list:REG_DEAD (reg:SI 462)
(nil)))
(insn 400 399 402 38 (set (reg:SI 465)
(gtu:SI (reg:CC 66 cc)
(const_int 0 [0]))) ./emit-rtl.c:1833 423 {aarch64_cstoresi}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(nil)))


Trying 397, 399 -> 400:
Successfully matched this instruction:
(set (reg:SI 465)
(const_int 1 [0x1]))
(const_int 1 [0x1])

It doesn't list the substitution before simplification, but it should be:

(set (reg:SI 465)
  (gtu:SI 
  (if_then_else:CC (ne (reg:SI 1002 [ ref_309(D)->codeD.85066 ]) 
   (const_int 47 [0x2f]))
(compare:CC (const_int 29 [0x1d]) (const_int 1 [0x1]))
(const_int 8 [0x8])))
  (const_int 0 [0])))

I don't see how it could simplify this unless it constant evaluates both the
then and else (despite CCmode type being special and needing extra care) and
decides they are both true, so the if-condition doesn't matter at all...

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #4 from Andrew Pinski  ---
Actually I think the problem is (const_int 8 [0x8])  does that make sense for
CC mode?  I don't think it does.

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #5 from Richard Henderson  ---
Created attachment 37419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37419=edit
proposed patch

I'm testing the following, but it does produce correct results
on a spot check of emit-rtl.c:1833.

We do leave a missed-optimization on the table, in that the
(compare:CC (const_int 29) (const_int 0)) subexpression isn't
optimized.  But that's something do addresss in gcc7.

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #6 from Wilco  ---
(In reply to Andrew Pinski from comment #4)
> Actually I think the problem is (const_int 8 [0x8])  does that make sense
> for CC mode?  I don't think it does.

It should make sense as a CCmode immediate. It relies on CCmode being treated
as an opaque type rather than an integer type. There are checks in several
places that block simplifications on CCmode, but I guess there are some missing
- it's the first time if_then_else has a CCmode result...

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #7 from Wilco  ---
(In reply to Richard Henderson from comment #5)
> Created attachment 37419 [details]
> proposed patch
> 
> I'm testing the following, but it does produce correct results
> on a spot check of emit-rtl.c:1833.

Yes, it looks right now.

> We do leave a missed-optimization on the table, in that the
> (compare:CC (const_int 29) (const_int 0)) subexpression isn't
> optimized.  But that's something do addresss in gcc7.

We could add patterns to handle some of these special cases, however the tree
optimizations should really have removed any redundant comparisons before RTL.

[Bug target/69416] [6 Regression] Nonsense rtl checking failure

2016-01-21 Thread rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416

--- Comment #3 from Richard Henderson  ---
(In reply to Wilco from comment #2)
> It doesn't list the substitution before simplification, but it should be:
> 
> (set (reg:SI 465)
>   (gtu:SI 
>   (if_then_else:CC (ne (reg:SI 1002 [ ref_309(D)->codeD.85066 ]) 
>(const_int 47 [0x2f]))
> (compare:CC (const_int 29 [0x1d]) (const_int 1 [0x1]))
> (const_int 8 [0x8])))
>   (const_int 0 [0])))
> 
> I don't see how it could simplify this unless it constant evaluates both the
> then and else (despite CCmode type being special and needing extra care) and
> decides they are both true, so the if-condition doesn't matter at all...

Combine's behaviour with CCmode is suspect, but I guess that the ELSE
portion of the inner IF needs more than a bare const_int.

I would write this as (unspec:CC [(const_int 8)] UNSPEC_NZCV).