[Bug lto/42528] ICE with -flto and -fsigned-char

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- 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