From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19024 invoked by alias); 3 Jan 2010 18:12:24 -0000 Received: (qmail 19006 invoked by uid 48); 3 Jan 2010 18:12:15 -0000 Date: Sun, 03 Jan 2010 18:12:00 -0000 Message-ID: <20100103181215.19005.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug lto/42528] ICE with -flto and -fsigned-char In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00301.txt.bz2 ------- 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 = ( *) __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