On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson <r...@redhat.com> wrote: > On 07/13/2011 08:35 AM, H.J. Lu wrote: >> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <r...@redhat.com> wrote: >>> On 07/13/2011 07:02 AM, H.J. Lu wrote: >>>> Hi Richard, >>>> >>>> Is my patch OK? >>> >>> No, I don't think it is. >>> >> >> What is your suggestion? > > Promote the return value. If that means it doesn't match function_value, > then I suggest that function_value is wrong. > >
static enum machine_mode ix86_promote_function_mode (const_tree type, enum machine_mode mode, int *punsignedp, const_tree fntype, int for_return) { if (type != NULL_TREE && POINTER_TYPE_P (type)) { *punsignedp = POINTERS_EXTEND_UNSIGNED; return Pmode; } return default_promote_function_mode (type, mode, punsignedp, fntype, for_return); } doesn't work. I got In file included from /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_div_macros.h:27:0, from /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid128_div.c:25: /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h: In function \u2018handle_UF_128.constprop.7\u2019: /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h:1626:1: internal compiler error: in emit_move_insn, at expr.c:3349 Please submit a full bug report, with preprocessed source if appropriate. TARGET_FUNCTION_VALUE shouldn't promote pointers to Pmode since it will also promote pointers passed in memory, which aren't needed nor desired. Since x86-64 processors ALWAYS zero-extend 32bit to 64bit when writing 32bit registers, it is OK not to promote pointers in TARGET_FUNCTION_VALUE. We only need to promote pointers to static enum machine_mode ix86_promote_function_mode (const_tree type, enum machine_mode mode, int *punsignedp, const_tree fntype, int for_return) { if (for_return == 1) /* Do not promote function return values. */ ; else if (type != NULL_TREE && POINTER_TYPE_P (type)) { *punsignedp = POINTERS_EXTEND_UNSIGNED; return Pmode; } return default_promote_function_mode (type, mode, punsignedp, fntype, for_return); } Richard, can you tell me what the real problem with my approach is? Thanks. -- H.J.