This patch looks fine to me.

2010/10/5 Min Zhao <mzhao...@gmail.com>

> Hi,
>
> I reevaluated the fix for this bug (bug611). It seems that we should not
> set_TY_return_in_mem for complex return type in wgen. As described in the
> comment, the design philosphy seems to be "wgen handles return_in_ memory
> based on high-level language requirements and back-end handle handles
> return_in_memory based on ABI". In this case, complex type return should be
> handled by back-end (lowering phase).
>
> Thus, my new fix is in WGEN_Handle_Named_Return_Value, do not assert when
> return type is not TY_return_in_mem. Instead, just return and let lower
> phase handle complex type return.
> Would a gatekeeper please review it again?
>
> Thanks,
>
> Min
>
> Index: wgen_spin_symbol.cxx
> ===================================================================
> --- wgen_spin_symbol.cxx        (revision 3366)
> +++ wgen_spin_symbol.cxx        (working copy)
> @@ -606,10 +606,6 @@
>                 default:  FmtAssert(FALSE, ("Get_TY unexpected size"));
>                 }
>                 idx = MTYPE_To_TY (mtype);      // use predefined type
> -        // gcc FE will set the complex type with size larger than 12 to be
> -        // return_in_memory in m32 mode (e.g., gcc/config/i386/i386.c)
> -        if (!TARGET_64BIT && tsize > 12)
> -            Set_TY_return_in_mem(idx);
>                 break;
>         case GS_POINTER_TYPE:
>                 if (gs_type_ptrmem_p(type_tree)) {
> Index: wgen_decl.cxx
> ===================================================================
> --- wgen_decl.cxx       (revision 3366)
> +++ wgen_decl.cxx       (working copy)
> @@ -5268,11 +5268,13 @@
>    // table in order to generate DWARF for it.  Bug 4900.
>    Get_ST(named_ret_obj);
>
> -  // The return type should be returned in memory.
>    TY_IDX ret_ty_idx = Get_TY(gs_tree_type(gs_tree_type(fn)));
> -  FmtAssert(TY_return_in_mem(ret_ty_idx),
> -           ("WGEN_Handle_Named_Return_Value: nrv type not in mem"));
>
> +  // It is possible that g++ does nvr for complex type.
> +  // We won't do anything in such case, since lowering phase will handle
> it
> +  // according to ABI.
> +  if (!TY_return_in_mem(ret_ty_idx)) return;
> +
>    // Get the ST for the fake first parm.
>    WN *first_formal = WN_formal(Current_Entry_WN(), 0);
>
> Index: wgen_stmt.cxx
> ===================================================================
> --- wgen_stmt.cxx       (revision 3366)
> +++ wgen_stmt.cxx       (working copy)
> @@ -2332,9 +2332,8 @@
>      // object is created by a TARGET_EXPR, have the TARGET_EXPR write
> directly
>      // to the memory return area.
>      if (TY_return_in_mem(ret_ty_idx)) {
> -      FmtAssert (TY_mtype (ret_ty_idx) == MTYPE_M ||
> -        !TARGET_64BIT && MTYPE_is_complex(TY_mtype(ret_ty_idx)) &&
> TY_mtype (ret_ty_idx) != MTYPE_C4,
> -                ("WGEN_Expand_Return: return_in_mem type is not MTYPE_M or
> complex type"));
> +      FmtAssert (TY_mtype (ret_ty_idx) == MTYPE_M,
> +                ("WGEN_Expand_Return: return_in_mem type is not
> MTYPE_M"));
>        // Skip the NOP_EXPRs, if any, before the TARGET_EXPR.  Bug 3448.
>        gs_t t = retval;
>        while (gs_tree_code(t) == GS_NOP_EXPR) {
> @@ -2508,9 +2507,8 @@
>        // Copy the return value into the return area.  Based on code in
>        // lower_return_val().
>
> -      FmtAssert (TY_mtype (ret_ty_idx) == MTYPE_M ||
> -      !TARGET_64BIT && MTYPE_is_complex(TY_mtype(ret_ty_idx)) && TY_mtype
> (ret_ty_idx) != MTYPE_C4,
> -                ("WGEN_Expand_Return: return_in_mem type is not MTYPE_M or
> complex type"));
> +      FmtAssert (TY_mtype (ret_ty_idx) == MTYPE_M,
> +                ("WGEN_Expand_Return: return_in_mem type is not
> MTYPE_M"));
>
>        WN *first_formal = WN_formal(Current_Entry_WN(), 0);
>        TY_IDX tidx = ST_type(WN_st(first_formal));
>



-- 
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to