[Bug target/46878] New: V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[Bug target/46878] New: V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[monaka@monami-software.com]

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

           Summary: V850 ICE in in maybe_add_or_update_dep_1, at
                    sched-deps.c:854
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: monaka@monami-software.com
              Host: i386-apple-darwin10.5.0
            Target: v850-elf
             Build: i386-apple-darwin10.5.0


/Volumes/git/pf3gnuchains4x/newlib/libc/search/hash_bigkey.c:669:1: internal
compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:854

The error message is avobe.

Attachment is the pre-processed source

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[monaka@monami-software.com]

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

--- Comment #1 from Masaki MURANAKA <monaka@monami-software.com> 2010-12-10 00:52:55 UTC ---
Created attachment 22699
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22699
Pre-processed source.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[monaka@monami-software.com]

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

--- Comment #2 from Masaki MURANAKA <monaka@monami-software.com> 2010-12-10 01:47:35 UTC ---
Created attachment 22701
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22701
simplified source


Additional info : the result of xgcc is
gcc version 4.6.0 20101207 (experimental) (GCC)

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[monaka@monami-software.com]

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

--- Comment #3 from Masaki MURANAKA <monaka@monami-software.com> 2010-12-10 02:35:53 UTC ---
This issue will depends  -m and -O option.

  cc1 -mv850 -O2 testcase-min6.i
  cc1 -mv850e1 -O2 testcase-min6.i
  cc1 -mv850e testcase-min6.i
  cc1 -mv850e2 testcase-min6.i
  cc1 -mv850e2v3 testcase-min6.i
wiil return with the normal exit.

  cc1 -mv850e -O2 testcase-min6.i
  cc1 -mv850e2 -O2 testcase-min6.i
  cc1 -mv850e2v3 -O2 testcase-min6.i
will return
  testcase-min6.i: In function ‘get_ice’:
  testcase-min6.i:21:1: internal compiler error: in maybe_add_or_update_dep_1,
at sched-deps.c:854
  Please submit a full bug report,

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[monaka@monami-software.com]

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

--- Comment #4 from Masaki MURANAKA <monaka@monami-software.com> 2010-12-10 15:02:06 UTC ---
I succeeded to build.
I'm not sure if the patch follows is reasonable... yah, indeed quite ugly.

Does anyone fix this? please,

diff --git a/gcc/config/v850/v850.md b/gcc/config/v850/v850.md
index d488b8b..9c98106 100644
--- a/gcc/config/v850/v850.md
+++ b/gcc/config/v850/v850.md
@@ -955,6 +955,8 @@
       if (GET_CODE (operands[3]) != REG)
        operands[3] = copy_to_mode_reg (SImode, operands[3]);
     }
+if (((enum rtx_code) (operands[0])->frame_related))
+   FAIL;
 }")

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie <dj at redhat dot com> 2011-01-18 01:46:00 UTC ---
Created attachment 23014
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23014
alternate patch

Alternate patch.  The v850.md patch tests frame_related, which is set for REGS
only to indicate that the value is a pointer, which "fixed" this bug only by
coincidence.  I think what's happening is that the v850 backend is generating a
BB that starts with a label, so fixup_sched_groups uses
prev_nonnote_nondebug_insn() and finds the label.  However, the functions it
calls expects only an INSN.  This patch adds a check for an INSN, to avoid
adding deps on labels.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> 2011-01-18 13:43:10 UTC ---
Why is the comparison marked with SCHED_GROUP_P?  I think that's your
underlying problem as SCHED_GROUP_P indicates the current insn must be
scheduled with the previous insn.  But there is no previous insn in the block.

(gdb) p debug_bb_n (4)
;; basic block 4, loop depth 0, count 0
;; prev block 3, next block 5
;; pred:       2 [50.0%] 
;; succ:       7 [78.4%]  5 [21.6%]  (fallthru)
;; bb 4 artificial_defs: { }
;; bb 4 artificial_uses: { u17(3){ }u18(29){ }u19(34){ }u20(35){ }}
;; lr  in       3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47 48
;; lr  use      3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47
;; lr  def      42 44
;; live  in       3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47 48
;; live  gen      42 44
;; live  kill    

(code_label 20 62 21 4 2 "" [1 uses])
(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 22 21 23 4 NOTE_INSN_DELETED)
(insn/s 23 22 60 4 (set (reg/v:SI 44 [ c ])
        (ne:SI (cc0)
            (const_int 0 [0]))) j.c:10 40 {*setcc}
     (nil))
(note 60 23 59 4 NOTE_INSN_DELETED)
(insn 59 60 30 4 (set (reg/v/f:SI 42 [ tmpp ])
        (if_then_else:SI (ne (reg:SI 43 [ D.1959 ])
                (const_int 1 [0x1]))
            (reg/v/f:SI 47 [ op ])
            (const_int 0 [0]))) j.c:15 46 {*movsicc_normal}
     (expr_list:REG_DEAD (reg/v/f:SI 47 [ op ])
        (expr_list:REG_DEAD (reg:SI 43 [ D.1959 ])
            (nil))))
(insn 30 59 31 4 (set (cc0)
        (compare (reg/v/f:SI 42 [ tmpp ])
            (const_int 0 [0]))) j.c:16 16 {cmpsi_insn}
     (expr_list:REG_DEAD (reg/v/f:SI 42 [ tmpp ])
        (nil)))
(jump_insn 31 30 32 4 (set (pc)
        (if_then_else (ne (cc0)
                (const_int 0 [0]))
            (label_ref:SI 50)
            (pc))) j.c:16 53 {*branch_normal}
     (expr_list:REG_BR_PROB (const_int 7837 [0x1e9d])
        (nil))
 -> 50)
;; lr  out      3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 44 48
;; live  out      3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 44 48



Note the /s on insn 23.  That's SCHED_GROUP_P.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.18 13:46:50
     Ever Confirmed|0                           |1

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com

--- Comment #7 from DJ Delorie <dj at redhat dot com> 2011-01-21 22:21:48 UTC ---
sched-deps:sched_analyze_2 has this:

#ifdef HAVE_cc0
    case CC0:
      /* User of CC0 depends on immediately preceding insn.  */
      SCHED_GROUP_P (insn) = 1;

But the conditional before the setcc was deleted (that's insn 22).
So the comment above is wrong in this case; there is no immediately preceeding
insn.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23014|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |dj at redhat dot com
                   |gnu.org                     |

--- Comment #8 from DJ Delorie <dj at redhat dot com> 2011-01-21 22:31:37 UTC ---
Created attachment 23074
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23074
alternate patch 2

This one checks to make sure there *is* an immediately preceeding insn. 
Better?

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 00:31:30 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 15:22, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> DJ Delorie <dj at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |dj at redhat dot com
> 
> --- Comment #7 from DJ Delorie <dj at redhat dot com> 2011-01-21 22:21:48 UTC ---
> sched-deps:sched_analyze_2 has this:
> 
> #ifdef HAVE_cc0
>     case CC0:
>       /* User of CC0 depends on immediately preceding insn.  */
>       SCHED_GROUP_P (insn) = 1;
> 
> But the conditional before the setcc was deleted (that's insn 22).
> So the comment above is wrong in this case; there is no immediately preceeding
> insn.
When the conditional was deleted, was SCHED_GROUP_P set on the following
insn?

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOiVEAAoJEBRtltQi2kC76uYH/0HO/T/PXYL4kSaGWolf3MIh
C2IyMaRqSRLtjVN1y2YGTF1JE8UezHwWv9rYY9NzgaIAFpBoCQ0QYK3fxJXz5pH8
2yEq64LsNcnlCSrNy8NKgdqc3l3a2KaiT4ZVwqsflPnrrxt3LZElx+zrdXOAz7Me
5GFsHOpG6PfOcd9WNwD+Os54Fx5UB8ooMk4DZFf30rHe6HUMJf0kvwHambAfLXXx
4AnEAz90iyUaFGK37rNxVRTlzk33rWaNA+8rJrA54IcqLN7Q8fCugAqp5xT2152r
+jDITL376B+vZB7J1HTnelgZ2fZvOOZkx0A7bh+QUablG3arkx06InMbRI+AhtE=
=k4Kp
-----END PGP SIGNATURE-----

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 00:33:26 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 15:32, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> DJ Delorie <dj at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   Attachment #23014|0                           |1
>         is obsolete|                            |
>              Status|NEW                         |ASSIGNED
>          AssignedTo|unassigned at gcc dot       |dj at redhat dot com
>                    |gnu.org                     |
> 
> --- Comment #8 from DJ Delorie <dj at redhat dot com> 2011-01-21 22:31:37 UTC ---
> Created attachment 23074
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23074
> alternate patch 2
> 
> This one checks to make sure there *is* an immediately preceeding insn. 
> Better?
I'm still quite concerned you're papering over the problem.  Can you
give a dump immediately before the setcc is removed?

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOiXEAAoJEBRtltQi2kC7QYwIAIzmPzqeKqI5wyRACB4F0dLu
CeCWykoaGKSP5b/zHNB6eEethxcOKh2VC8vcpLkmaqx7zMGRx3biUAlrz0D/SXZc
0RWlQyPx2j+sUYWZbcNZbfH3b2Osl8AgsC7d3llKJK5zdkR1UYbS2hURodjyb/Y0
OjtyWD0layQQZ9/sCB8yZHTb7CRvPMDxHl4+vEe0vEBeGIHGsmOJRuR/iICqPm4O
EVV2A4x0ZCc5TAwdGZacyeJZN4chIW/BTlKDfyliCEnwjg0zpFwwH/uA+42EHd8y
I0kD86BhN/9D89WjiLxgpVXGGw91AE1ZWVdopDtpePppq+gV4++KsDnaE0DapBg=
=rJ+i
-----END PGP SIGNATURE-----

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

--- Comment #11 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:37:35 UTC ---
I set a breakpoint on the delete of that insn; at that time, the following insn
did not have the /S set on it.  At the time when the /S is added, the previous
insn had already been deleted.  So, it's delete first, set /s second, crash
third.

And it's not the setcc that's delted, it's the (compare) before it.  The setcc
is the one with the /s on it.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

--- Comment #12 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:40:44 UTC ---
Of course, one could argue that perhaps the compare should *not* have been
removed?  I don't know how clever the new redundant compare removal code is.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 00:42:52 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 17:38, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> --- Comment #11 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:37:35 UTC ---
> I set a breakpoint on the delete of that insn; at that time, the following insn
> did not have the /S set on it.  At the time when the /S is added, the previous
> insn had already been deleted.  So, it's delete first, set /s second, crash
> third.
OK.  That means one of two things.   Either the comparison shouldn't
have been deleted or we shouldn't have added SCHED_GROUP_P to the setcc.

> 
> And it's not the setcc that's delted, it's the (compare) before it.  The setcc
> is the one with the /s on it.
I know.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOif2AAoJEBRtltQi2kC7tmQH/3BQml/X2yyb1QZpVr5jYNE7
e8f1StC+ktqaBgSr2nrclg/uIj8LontEPU+oOY3r9Ee56TWnBAVIe1b7nJ1H0MmX
Kbfw1zFR5/xABoiOZiiAqGEulLiJpFEiC9yaucpQZBkUDjCKP/Lzt6xknuBKUxdJ
IBIhNOQjBeFtopV0L88N2QfhLGiaV05RIbqVQHnYG6ti7GK0RErWP+jh14WaLPtV
i0BcQ+2gzGKhBXLUS4BXC8O/T0ft87/uOhOp2O0u5v1j0zxS+dCcAVyGGKaDCDbs
8OCuOaYPDn52KH0YeQmVsQgexDLG21DrWr8QSzaLw8qkYg00XpM27xT6kZf9Yac=
=8vRi
-----END PGP SIGNATURE-----

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 00:50:25 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 17:41, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> --- Comment #12 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:40:44 UTC ---
> Of course, one could argue that perhaps the compare should *not* have been
> removed?  I don't know how clever the new redundant compare removal code is.
That's part of why I want a dump -- I seem to recall rules about
removing comparisons on cc0 machines and reading the dumps may help me
recall what those rules are.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOim8AAoJEBRtltQi2kC7G5YIAIh7Nfv7ALDaKC3QwbKoqaXw
7zXr66Z1ephIXWQ/4eav6y7EXVapTl546ygOCjZg3IHEy2g0BJxwUzJk2vbIcbM9
1WnWQizMQdjGUcjSNtJsntoB5Yx7+xo4Y7ENeUct+yeQNPx19gkQ0H11mUuBY5ZV
Mqli07f0nzZ5dwWvdwoSngbYKMtgfYL6cIBsKVDvRPdHSGWH/27bcG0ExjCwTZsm
5AcVxRLrmD/FcqDXTW8sZEVyms0sEdmBb2v9eL6TlEqmzvVOZlSj2IjjNePYD4KY
O9VDU3ZgoHdrr8fzaW3ZsKyCrAwLVZZ1mYHeJt1nqnif64w4X++XRxZtlOGT1uM=
=S5Gb
-----END PGP SIGNATURE-----

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #15 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 04:03:24 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 17:41, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> --- Comment #12 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:40:44 UTC ---
> Of course, one could argue that perhaps the compare should *not* have been
> removed?  I don't know how clever the new redundant compare removal code is.
I'm thinking that is the fundamental problem.

This appears to be a HAVE_cc0 target.  On a cc0 target the setter and
user must always remain consecutive.  The reason for that is insns
implicitly set cc0, which isn't reflected in the rtl/dataflow.  So if we
allowed anything in between setter & user it might clobber the flags
unexpectedly.


Prior to combine you have this:

(code_label 20 17 21 4 2 "" [1 uses])

(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 22 21 23 4 (set (cc0)
        (compare (reg:SI 43 [ D.1959 ])
            (const_int 1 [0x1]))) test.c:10 16 {cmpsi_insn}
     (expr_list:REG_DEAD (reg:SI 43 [ D.1959 ])
        (nil)))

(insn 23 22 60 4 (set (reg/v:SI 44 [ c ])
        (ne:SI (cc0)
            (const_int 0 [0]))) test.c:10 40 {*setcc}
     (nil))


Everything looks fine and dandy.  The cc0 setter and cc0 user are
consecutive insns.

After combine you have:

(code_label 20 17 21 4 2 "" [1 uses])

(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(note 22 21 23 4 NOTE_INSN_DELETED)

(insn 23 22 60 4 (set (reg/v:SI 44 [ c ])
        (ne:SI (cc0)
            (const_int 0 [0]))) test.c:10 40 {*setcc}
     (nil))

(note 60 23 59 4 NOTE_INSN_DELETED)


Even if insn 22 was redundant on the paths leading to code_label 20, on
a HAVE_cc0 target, the cc0 setter and cc0 user must remain consecutive
insns thus deleting insn 22 is incorrect.


So, you need to track down why combine decides it's OK to delete insn 22.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOlb2AAoJEBRtltQi2kC778wH/3fsKS9yq2BBqjK1cWFHbbkp
1IqAwk2cZAOYLWgtAIrmRKkoUAIKi7rqKzNfvy7qWJwtpLavX1SvQ69e4EBtc67R
ZdSq05H3n1MzU6tRx/TcF/SjMlO0vAct/AOSI6TvHK59eZGoYGSa0Mqaqw7LQCT+
zX4aT2x09w/tNA4qJgBLoEEw71dIfEszACz9F3T6k2ZMIHjyPQoBzt7k0YKGOcDU
0uv89djEHVmvr0mFkF7k5Pn/RlytibDVy/43aKUCmflWvsj7BsOkrKfruHDSdGtI
Yg9Zd2MPCDQ2gHrN0VaxOFITjwgMf9takt4gJYqKGOJMFcyiiaFlKSAgQlt0/bs=
=xVgr
-----END PGP SIGNATURE-----

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23074|0                           |1
        is obsolete|                            |

--- Comment #16 from DJ Delorie <dj at redhat dot com> 2011-01-25 23:41:53 UTC ---
Created attachment 23126
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23126
alternate patch 3

Another patch attempt.  In this case, we add a check for the implied dependency
created by a cc0 setter/user pair to insn_a_feeds_b() so that try_combine()
knows that the cc0 setter is needed if the user is needed.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

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

--- Comment #17 from Jeffrey A. Law <law at redhat dot com> 2011-01-26 14:10:28 UTC ---
*** Bug 47459 has been marked as a duplicate of this bug. ***

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.6.0

--- Comment #18 from Jeffrey A. Law <law at redhat dot com> 2011-01-26 14:12:53 UTC ---
Note we're seeing this failure on m68k as well and it's a regression.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug rtl-optimization/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
          Component|target                      |rtl-optimization
   Target Milestone|---                         |4.6.0

[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #19 from Mikael Pettersson <mikpe at it dot uu.se> 2011-01-26 14:50:28 UTC ---
(In reply to comment #18)
> Note we're seeing this failure on m68k as well and it's a regression.

Could it be related to PR46856 (a HAVE_cc0 postreload regression from r162270
that's breaking m68k-linux)?

[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

--- Comment #20 from Jeffrey A. Law <law at redhat dot com> 2011-01-26 14:56:14 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/11 07:51, mikpe at it dot uu.se wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> Mikael Pettersson <mikpe at it dot uu.se> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |mikpe at it dot uu.se
> 
> --- Comment #19 from Mikael Pettersson <mikpe at it dot uu.se> 2011-01-26 14:50:28 UTC ---
> (In reply to comment #18)
>> Note we're seeing this failure on m68k as well and it's a regression.
> 
> Could it be related to PR46856 (a HAVE_cc0 postreload regression from r162270
> that's breaking m68k-linux)?
It's related in the sense that both are problems with cc0 targets, but I
doubt the underlying root cause is the same.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQDYBAAoJEBRtltQi2kC7r+cH/28xx5O9b7ll8SqYuNMwAIQP
vJEStmdjxFEP84DOXd7WPPPyW4qwdEfy2ufFCgorX9MYbyNkxAYGcT96CQUX5jVU
z/u+69tzrLwDwcNQ75tLb+THJVwiyUCIz52bNdXo2rHWKGy2yXM+97zdhnBmSNoA
Vrr+bLnESl0WiDFxdwlSJALTAEXyRaj4iXR+LR8yN/ewt1bsTt4hIaMmyKcNLuV+
ASOnhFl4x/q+QoURdj9Fd8d2taLVGbKtCeZkPl4nktTp6NvQl4vGBeKgZkHNkZPU
RITPyew6a3ISICFNeXlsDjbAnToJQcPoa187AcSlwOLCLdoES53B/qUEZdlZHDc=
=uQnW
-----END PGP SIGNATURE-----

--- Comment #21 from Jeffrey A. Law <law at redhat dot com> 2011-01-26 15:23:15 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/11 16:42, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> DJ Delorie <dj at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   Attachment #23074|0                           |1
>         is obsolete|                            |
> 
> --- Comment #16 from DJ Delorie <dj at redhat dot com> 2011-01-25 23:41:53 UTC ---
> Created attachment 23126
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23126
> alternate patch 3
> 
> Another patch attempt.  In this case, we add a check for the implied dependency
> created by a cc0 setter/user pair to insn_a_feeds_b() so that try_combine()
> knows that the cc0 setter is needed if the user is needed.
I think you're on the right track here.  I want to look at it a bit
more, but this might be "it".

FWIW, this code was a relatively recent addition to combine to support
four insn combinations and just happens to be the code I was concerned
might not be cc0-safe.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQDxTAAoJEBRtltQi2kC7DqEH/jTegxTzt00RTBmi9pfN77TY
4XdhGv8KZsiFsiEp+IsBdQWhY7xJ12nHwjrBGqz72hDDSoYMflrceIhYqhvPqs3E
BzIGmsccr5s+LD/qBQi8bqENOxlADytFia8QpRn22s17v1VhLnk321pFHvS2552G
RDASg+ZPnYwrQL9dSKNQ4DKN/W3sTSGe3wLjpSYlhUp4jZ3MjLCMhkLAWaRZ8tWi
Q+SfJz5a9bX8sgGCG1Utio0kEhqLYzkgxvgNJoi04059WWuB6uwlsWGcjbd23UTA
hjnPRFxpetJp4En7NCOW2eo+2AC97NM909aXwAnvJWUBezDSYZu8fhSbE1rQrjA=
=lw6z
-----END PGP SIGNATURE-----

--- Comment #22 from Jeffrey A. Law <law at redhat dot com> 2011-01-26 16:40:32 UTC ---
Patch attempt #3 is OK.  Please keep an eye out for complains about cc0 targets
not creating loop (dbra) insns.  That's my only worry.  I don't think it's
going to be a problem, but I can't completely rule it out.

Thanks for your patience,
Jeff

[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at gcc dot gnu.org]

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

--- Comment #23 from dj at gcc dot gnu.org <dj at gcc dot gnu.org> 2011-01-26 22:03:50 UTC ---
Author: dj
Date: Wed Jan 26 22:03:47 2011
New Revision: 169307

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169307
Log:
PR rtl-optimization/46878
* combine.c (insn_a_feeds_b): Check for the implicit cc0
setter/user dependency as well.

* gcc.dg/pr46878-1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr46878-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dj at redhat dot com]

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

DJ Delorie <dj at redhat dot com> changed:

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

--- Comment #24 from DJ Delorie <dj at redhat dot com> 2011-01-26 23:21:30 UTC ---
Resolved in git commit 169307.

[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[dnovillo at gcc dot gnu.org]

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

--- Comment #25 from Diego Novillo <dnovillo at gcc dot gnu.org> 2011-02-02 17:55:04 UTC ---
Author: dnovillo
Date: Wed Feb  2 17:54:59 2011
New Revision: 169631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169631
Log:
PR rtl-optimization/46878
* combine.c (insn_a_feeds_b): Check for the implicit cc0
setter/user dependency as well.

* gcc.dg/pr46878-1.c: New test.

Added:
    branches/google/integration/gcc/testsuite/gcc.dg/pr46878-1.c
Modified:
    branches/google/integration/gcc/ChangeLog
    branches/google/integration/gcc/combine.c
    branches/google/integration/gcc/testsuite/ChangeLog