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));
------------------------------------------------------------------------------
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