https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
ktkachov at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #16 from ktkachov at gcc dot gnu.org ---
The reduced testcase for aarch64 at -O3 is:
using UINT8 = char;
using UINT32 = int;
using UINT64 = long;
class A {
void m_fn1();
struct B {
UINT32 m_multiplier;
};
UINT8 m_datawidth;
UINT8 m_subunits;
B m_subunit_infos[];
};
int a;
UINT64 b;
void A::m_fn1() {
int c = 32, d = m_datawidth / c;
for (int e = 0; e < d; e++) {
UINT32 f = e * 32;
if (b >> f & 1)
m_subunit_infos[m_subunits].m_multiplier = a;
}
}
The aarch64 patterns for extzv and *tb<optab><mode>1 don't have the appropriate
predicates on their zero extract operands and end up allowing silly values like
192.
They should be fixed, but the zero_extract patterns are being formed in
combine. ISTR combine started forming zero_extracts more aggressively in GCC 6
but shouldn't it avoid forming them when the RTX it generates is clearly bogus
like:
(zero_extract:DI (reg:DI 75 [ b.0_3 ])
(const_int 1 [0x1])
(const_int 192 [0xc0]))
?
