diff options
| author | Andrew Pinski <apinski@marvell.com> | 2023-09-14 07:39:31 -0700 |
|---|---|---|
| committer | Andrew Pinski <apinski@marvell.com> | 2023-09-15 07:27:12 -0700 |
| commit | ba4c1f2bfc9ec063188b39d0281fae04c57b1416 (patch) | |
| tree | c423a5d95a5eb646c159783391328fc141dbcf69 /gcc/analyzer/infinite-recursion.cc | |
| parent | 76a2d567842088ff296609c9e3b53c3df179aefd (diff) | |
| download | gcc-ba4c1f2bfc9ec063188b39d0281fae04c57b1416.zip gcc-ba4c1f2bfc9ec063188b39d0281fae04c57b1416.tar.gz gcc-ba4c1f2bfc9ec063188b39d0281fae04c57b1416.tar.bz2 | |
MATCH: Fix `(1 >> X) != 0` pattern for vector types
I had missed that integer_onep can match vector types with uniform constant of `1`.
This means the shifter could be an scalar type and then doing a comparison against `0`
would be an invalid transformation.
This fixes the problem by adding a check for the type of the integer_onep to make
sure it is a INTEGRAL_TYPE_P (which does not match a vector type).
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/111414
gcc/ChangeLog:
* match.pd (`(1 >> X) != 0`): Check to see if
the integer_onep was an integral type (not a vector type).
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr111414-1.c: New test.
Diffstat (limited to 'gcc/analyzer/infinite-recursion.cc')
0 files changed, 0 insertions, 0 deletions