[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2016-11-11 00:00:00         |2017-01-19
                 CC|                            |law at redhat dot com
     Ever confirmed|0                           |1

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
So I was able get this to fail with a cross using:

commit 6a1bfa32ecedcf735adfb9ac660c0e659a04764a
Author: gccadmin <gccadmin@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sun Nov 6 00:16:15 2016 +0000

    Daily bump.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241882
138bc75d-0d04-0410-961f-82ee72b054a4

And the configuration target & options from c#2.  It could well be sensitive to
those in one way or another.  Anyway, once reproduced bisection landed on:

commit 9cd62877282864d0c98bb0d4eaedfc83c77df843
Author: kelvin <kelvin@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sat Dec 17 00:18:32 2016 +0000

    gcc/testsuite/ChangeLog:

    2016-12-16  Kelvin Nilsen  <kelvin@gcc.gnu.org>

        * gcc.target/powerpc/byte-in-either-range-0.c: New test.
        * gcc.target/powerpc/byte-in-either-range-1.c: New test.
        * gcc.target/powerpc/byte-in-range-0.c: New test.
        * gcc.target/powerpc/byte-in-range-1.c: New test.
        * gcc.target/powerpc/byte-in-set-0.c: New test.
        * gcc.target/powerpc/byte-in-set-1.c: New test.
        * gcc.target/powerpc/byte-in-set-2.c: New test.


    gcc/ChangeLog:

    2016-12-16  Kelvin Nilsen  <kelvin@gcc.gnu.org>

        * config/rs6000/altivec.md (UNSPEC_CMPRB): New unspec value.
        (UNSPEC_CMPRB2): New unspec value.
        (UNSPEC_CMPEQB): New unspec value.
        (cmprb): New expansion.
        (*cmprb_internal): New insn.
        (*setb_internal): New insn.
        (cmprb2): New expansion.
        (*cmprb2_internal): New insn.
        (cmpeqb): New expansion.
        (*cmpeqb_internal): New insn.
        * config/rs6000/rs6000-builtin.def (BU_P9_2): New macro.
        (BU_P9_64BIT_2): Likewise.
        (BU_P9_OVERLOAD_2): Likewise.
        (CMPRB): Add byte-in-range built-in function.
        (CMBRB2): Add byte-in-either-range built-in function.
        (CMPEQB): Add byte-in-set built-in function.
        (CMPRB): Add overload support for byte-in-range function.
        (CMPRB2): Add overload support for byte-in-either-range function.
        (CMPEQB): Add overload support for byte-in-set built-in function.
        * config/rs6000/rs6000-c.c (P9_BUILTIN_CMPRB): Macro expansion to
        define argument types for new builtin.
        (P9_BUILTIN_CMPRB2): Likewise.
        (P9_BUILTIN_CMPEQB): Likewise.
        * doc/extend.texi (PowerPC AltiVec Built-in Functions): Rearrange
        the order of presentation for certain built-in functions
        (scalar_extract_exp, scalar_extract_sig, scalar_insert_exp)
        (scalar_cmp_exp_gt, scalar_cmp_exp_lt, scalar_cmp_exp_eq)
        (scalar_cmp_exp_unordered, scalar_test_data_class)
        (scalar_test_neg) to improve locality and flow.  Document
        the new __builtin_scalar_byte_in_set,
        __builtin_scalar_byte_in_range, and
        __builtin_scalar_byte_in_either_range functions.

When I look at the actual committed patch I have trouble seeing how its
affecting things at all.  When I look at the dump diffs, it's a total confusing
mess.  We get diffs all over the tree dumps which makes no sense.  In the end
it looks like we miss an equivalence in tree-pre which in turn changes the
coalescing, which in turn changes the RTL we generate in all kinds of ways and
we don't tickle the bug.

I actually walked forward backing out the above mentioned patch and a couple
others that were not correctness fixes and was able to show the bug on the
trunk from just a couple days ago.  So I can say with a high degree of
confidence this is just latent on the trunk.

It does raise the question of how long we're going to support -mno-lra on PPC. 
If someone wants to investigate, I would start with that Nov 6 tree, properly
configured.  I've already got another "strange" bug I'm chasing down, so I
don't need another right now.