> Can't hurt, and debugging the assert tripping is likely a hell of a lot easier
> than debugging the resultant incorrect code. So if it passes, then I'd say go
> for it.
Testing passed, so I've committed it with those asserts (and thankfully I've
added them!) but it apparently broke Linux kernel build on arm.
The problem is that if the STRING_CST is very short, while the full object
has BLKmode, the short string could very well have
QImode/HImode/SImode/DImode and in that case it wouldn't take the path that
copies the string and then clears the remaining space, but different paths
in which it will ICE because of those asserts and without those it would
just emit wrong-code.
The following patch fixes it by enforcing BLKmode for the string MEM, even
if it is short, so that we copy it and memset the rest.
2020-05-31 Jakub Jelinek <jakub@redhat.com>
PR middle-end/95052
* expr.c (store_expr): For shortedned_string_cst, ensure temp has
BLKmode.
* gcc.dg/pr95052.c: New test.
(call_param_p
? EXPAND_STACK_PARM : EXPAND_NORMAL),
&alt_rtl, false);
+ if (shortened_string_cst)
+ {
+ gcc_assert (MEM_P (temp));
+ temp = change_address (temp, BLKmode, NULL_RTX);
+ }
}
/* If TEMP is a VOIDmode constant and the mode of the type of EXP is not
--- /dev/null
+/* PR middle-end/95052 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fconserve-stack" } */
+
+void bar (char *);
+
+void
+foo (void)
+{
+ char buf[70] = "";
+ bar (buf);
+}