[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 Andrew Pinski changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #11 from Andrew Pinski --- *** Bug 110272 has been marked as a duplicate of this bug. ***
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Andrew Pinski --- Fixed.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:3f085e45755643f13d4fa45a12a6ade45be98f95 commit r14-1601-g3f085e45755643f13d4fa45a12a6ade45be98f95 Author: Andrew Pinski Date: Sun Jun 4 19:42:08 2023 -0700 Handle const_int in expand_single_bit_test After expanding directly to rtl instead of creating a tree, we could end up with a const_int which is not ready to be handled by extract_bit_field. So need to the constant folding here instead. OK? bootstrapped and tested on x86_64-linux-gnu with no regressions. PR middle-end/110117 gcc/ChangeLog: * expr.cc (expand_single_bit_test): Handle const_int from expand_expr. gcc/testsuite/ChangeLog: * gcc.dg/pr110117-1.c: New test. * gcc.dg/pr110117-2.c: New test.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e60593f3881c72a96a3fa4844d73e8a2cd14f670 commit r14-1600-ge60593f3881c72a96a3fa4844d73e8a2cd14f670 Author: Andrew Pinski Date: Sun Jun 4 19:21:05 2023 -0700 Improve do_store_flag for single bit when there is no non-zero bits In r14-1534-g908e5ab5c11c, I forgot you could turn off CCP or turn off the bit tracking part of CCP so we would lose out what TER was able to do before hand. This moves around the TER code so that it is used instead of just the nonzerobits. It also makes it easier to remove the TER part of the code later on too. OK? Bootstrapped and tested on x86_64-linux-gnu. Note it reintroduces PR 110117 (which was accidently fixed after r14-1534-g908e5ab5c11c). The next patch in series will fix that. gcc/ChangeLog: * expr.cc (do_store_flag): Rearrange the TER code so that it overrides the nonzero bits info if we had `a & POW2`.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-June/62 ||0618.html --- Comment #7 from Andrew Pinski --- Patch submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620618.html
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117
--- Comment #6 from Andrew Pinski ---
Simplier testcase:
```
int f()
{
int t = 0;
return (t & 1) != 0;
}
```
Options are:
`-O1 -fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ccp -fno-tree-forwprop
-fno-tree-fre -fno-tree-copy-prop` .
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #5 from Andrew Pinski --- Created attachment 55255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55255=edit Patch which fixes this I am going to split this patch into 2, one for the do_store_flag change and one for the patch which fixes this part. The do_store_flag change is needed to hit this bug again.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #4 from Andrew Pinski --- This was "fixed" by r14-1534-g908e5ab5c11c64 as we don't have a nonzero bits on _5 in : # RANGE [irange] int [-2147483647, +INF] _4 = 0; _5 = _4 & 1; _39 = _5 != 0; Since we don't have a non-zero bits we don't look back at the TER to see it was &1 and we don't call into expand_single_bit_test . I am still going to fix expand_single_bit_test to do the correct thing for const_int but we no longer ICEs in the original testcase.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #3 from Andrew Pinski --- Anyways imode should just be operand_mode really. But that does not solve the issue either because extract_bit_field does not know how to handle const_int :(.
[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110117 --- Comment #2 from Andrew Pinski --- _4 = 0; _5 = _4 & 1; _39 = _5 != 0; The reason why it worked before was that when creating trees, it simplify down to 0 and then expand that. Now we are expanding directly to rtl, we get: (const_int 0) for inner and there is no mode associated with that.
