https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466
--- Comment #9 from tt_1 <herrtimson at yahoo dot de> ---
started with pr105998
commit 20bb976fb6a853d4f79577278ac2f01622946b61
Author: Jakub Jelinek <ja...@redhat.com>
Date: Sat, 18 Jun 2022 09:07:13 +0000
varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]
The following testcase ICEs because there is NON_LVALUE_EXPR (location
wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
is DImode, but SCALAR_INT_TYPE_MODE still uses the raw V2SImode and ICEs
too.
2022-06-18 Jakub Jelinek <ja...@redhat.com>
PR middle-end/105998
* varasm.c (narrowing_initializer_constant_valid_p): Check
SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P, also break on
! INTEGRAL_TYPE_P and do the same check also on op{0,1}'s type.
* c-c++-common/pr105998.c: New test.
here is how I did it:
the first bad version is 10.4.0-RC
the last good version is 10-20220616
Its just a handfull of commits between those snapshots, so I compiled
10-20220616 and added those commits subsequentially, via local patch files.
Its a problem though that cross-compiler doesn't confirm the ICE, and native
compile is kind if heisenbugging around. I'll ask the original author if he has
any suggestion what could happen here.
gcc-11.3.0 is not affected, as the fix landed for gcc-11.4.0 and I haven't yet
found the time to test these snapshots.
