https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org,
| |bergner at gcc dot gnu.org,
| |linkw at gcc dot gnu.org,
| |segher at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|ICE in ppc64-linux-gnu |ICE in ppc64-linux-gnu
|crosscompiler in |crosscompiler in
|store_by_pieces, at |store_by_pieces since
|expr.cc:1820 |r14-5946-g1ff6d9f7428b06
Keywords|needs-bisection |
Last reconfirmed| |2023-12-01
--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed, thanks for reporting, it starts from r14-5946-g1ff6d9f7428b06.
It looks function try_store_by_multiple_pieces has the wrong assumption. For
the code "memset (buf, 'v', 3)", it checks
+ if (max_bits < orig_max_bits
+ && xlenest + blksize >= xlenest
+ && can_store_by_pieces (xlenest + blksize,
+ builtin_memset_read_str,
+ &valc, align, true))
, succeeds and breaks. later it goes with blksize:
to = store_by_pieces (to, blksize,
constfun, constfundata,
align, true,
max_len != 0 ? RETURN_END : RETURN_BEGIN);
and fails at targetm.use_by_pieces_infrastructure_p assertion.
It's concluded that can_store_by_pieces (xlenest + blksize, ...) doesn't
necessarily means can_store_by_pieces (blksize, ...).
