https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-12 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:671b7c29dd666cb74dfe5ab01b501d6a0ca7b41c commit r12-9144-g671b7c29dd666cb74dfe5ab01b501d6a0ca7b41c Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Jan 25 10:50:27 2023 +0100 store-merging: Disable string_concatenate mode if start or end aren't byte aligned [PR108498] The first of the following testcases is miscompiled on powerpc64-linux -O2 -m64 at least, the latter at least on x86_64-linux -m32/-m64. Since GCC 11 store-merging has a separate string_concatenation mode which turns stores into setting a MEM_REF from a STRING_CST. This mode is triggered if at least one of the to be merged stores is a STRING_CST store and either the first store (to earliest address) is that STRING_CST store or the first store is 8-bit INTEGER_CST store and then there are some rules when to turn that mode off or not merge further stores into it. The problem with these 2 testcases is that the actual implementation relies on start/width of the store to be at byte boundaries, as it simply creates a char array, MEM_REF can be only on byte boundaries and the char array too, plus obviously STRING_CST as well. But as can be easily seen in the second testcase, nothing verifies this, while the first store has to be a STRING_CST (which will be aligned) or 8-bit INTEGER_CST, that 8-bit INTEGER_CST store could be a bitfield store, nothing verifies any stores in between whether they actually are 8-bit and aligned, the only major requirement is that all the stores are consecutive. For GCC 14 I think we should reconsider this, simply treat STRING_CST stores during the merging like INTEGER_CST stores and deal with it only during split_group where we can create multiple parts, this part would be a normal store, this part would be STRING_CST store, this part another normal store etc. But that is quite a lot of work, the following patch just disables the string_concatenate mode if boundaries aren't byte aligned in the spot where we disable it if it is too short too. If that happens, we'll just try to do the merging using normal 1/2/4/8 etc. byte stores as usually with RMW masking for any bits that shouldn't be touched or punt if we end up with too many stores compared to the original. Note, an original STRING_CST store will count as one store in that case, something we might want to reconsider later too (but, after all, CONSTRUCTOR stores (aka zeroing) already have the same problem, they can be large and expensive and we still count them as one store). 2023-01-25 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/108498 * gimple-ssa-store-merging.cc (class store_operand_info): End coment with full stop rather than comma. (split_group): Likewise. (merged_store_group::apply_stores): Clear string_concatenation if start or end aren't on a byte boundary. * gcc.c-torture/execute/pr108498-1.c: New test. * gcc.c-torture/execute/pr108498-2.c: New test. (cherry picked from commit 617be7ba436bcbf9d7b883968c6b3c011206b56c)
