https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86042
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 5 Jun 2018, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86042 > > --- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- > The strcpy() calls are first transformed into > > MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})"12"]; > > In GCC 7, the above is then transformed into > > MEM[(char * {ref-all})&a] = "12"; > > (I'm not sure what the difference is). "12" is considered a constant while MEM[(char * {ref-all})"12"] is considered a read from the constant pool. It's not simplified to that because GCC 8 uses 'unsigned char[]' as access type while GCC 7 used char[] and those are not compatible. I suspect if we change /* We get an aggregate copy. Use an unsigned char[] type to perform the copying to preserve padding and to avoid any issues with TREE_ADDRESSABLE types or float modes behavior on copying. */ desttype = build_array_type_nelts (unsigned_char_type_node, tree_to_uhwi (len)); in gimple_fold_builtin_memory_op to use char_type_node then we'll get back GCC 7 behavior for this case. (I chose unsigned char type to not change IL based on -f[un]signed-char) I suspect that with -funsigned-char the testcase already works with GCC8? " In GCC 7, the second instance of the > above is then removed in fre1. By means of redundant store removal which ATM only handles stores from constants and registers but not aggregate copies. > In GCC 8, the second instance makes it all the way to the strlen pass where > handle_char_store() isn't prepared to deal with it if a length record exists > for the destination. I think the strlen() limitation can be handled by the > same solution as bug 86043: i.e., have handle_char_store() handle cases where > substrings of any length is overwritten without changing their length, not > just > those of length one by plain character assignment. Yes, that's a good enhancement independent of this bug. > I don't know why the duplicate MEM assignment above isn't eliminated earlier > (that may be a separate bug). See above - redundant store removal doesn't handle aggregate copies.
