------- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-03 18:12 ------- Which seems to be because of CCP which folds
D.2023_3 = __builtin___strcpy_chk (&p[1], &"vwxyz"[0], 31); with unsigned LHS to D.2023_3 = (<unnamed-signed:8> *) __builtin_memcpy (&p[1], &"vwxyz"[0], 6); which requires a temporary and thus exposes the mismatched types to the verifier (we don't verify function assignments). Which is also because lto1 doesn't understand -f[un]signed-char and always has flag_signed_char set to the target default because 1044 /* Share char_type_node with whatever would be the default for the target. 1045 char_type_node will be used for internal types such as 1046 va_list_type_node but will not be present in the lto stream. */ 1047 char_type_node 1048 = DEFAULT_SIGNED_CHAR ? signed_char_type_node : unsigned_char_type_node; the comment is true, but still units with different setting of flag_signed_char will have different va_list_type_node and different function signatures for builtin string functions. Now the above together with LTO1 not recognizing -f[un]signed-char even breaks consistent but non-standard flag_signed_char setting. Whatever is more important ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
