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 <kel...@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 <kel...@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.