From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8976 invoked by alias); 17 Sep 2006 20:05:32 -0000 Received: (qmail 8949 invoked by uid 48); 17 Sep 2006 20:05:25 -0000 Date: Sun, 17 Sep 2006 20:05:00 -0000 Message-ID: <20060917200525.8948.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "danglin at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg01633.txt.bz2 List-Id: ------- Comment #3 from danglin at gcc dot gnu dot org 2006-09-17 20:05 ------- There's a question in my mind as to whether we should always be emitting a library call: /* When not optimizing, generate calls to library functions for a certain set of builtins. */ if (!optimize && !called_as_built_in (fndecl) && DECL_ASSEMBLER_NAME_SET_P (fndecl) && fcode != BUILT_IN_ALLOCA) return expand_call (exp, target, ignore); The setting of DECL_ASSEMBLER_NAME doesn't seem to be entirely reliable. We have in builtin_function: if (library_name) SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name)); library_name is set for __builtin_memcpy but not for memcpy. The difference in behavior between the 32-bit hpux targets and the 32-bit linux target arises because the hpux target defines ASM_OUTPUT_EXTERNAL. So, the assembler name for memcpy gets set indirectly by assemble_external_real and this causes expand_builtin to use the library routine. Is this the intended behavior? Ok, back to looking at the linux SEGV. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111