This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/42528] ICE with -flto and -fsigned-char
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Jan 2010 18:12:15 -0000
- Subject: [Bug lto/42528] ICE with -flto and -fsigned-char
- References: <bug-42528-8090@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot 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