Hi,

Would a gatekeeper please review the change for bug664?
https://bugs.open64.net/show_bug.cgi?id=664

Here is the failing testcase:

struct st1{
  int *a;
  int b;
};

int main()
{
struct st1 myst;
myst.b = 10;
int k;

k = (0, myst).b;

printf("%d\n", k);
}

We are generating incorrect IR for comma expression (0, myst).b:
  MMLDID 0 <2,1,myst> T<53,st1,8>
 I4STID 0 <2,2,k> T<4,.predef_I4,4> {line: 12}

instead of
  I4I4LDID 8 <2,1,myst> T<53,st1,8> <field_id:2>
 I4STID 0 <2,2,k> T<4,.predef_I4,4> {line: 12}

The problem is in WGEN_Expand_Expr, when processing GS_COMPOUND_EXPR case,
it does not pass the correct information (e.g., field_id) to the following
WGEN_Expand_Expr call (for its child).

The following is my patch.

Thanks,

Min

Index: wgen_expr.cxx
===================================================================
--- wgen_expr.cxx       (revision 3364)
+++ wgen_expr.cxx       (working copy)
@@ -9810,7 +9810,8 @@
 #ifdef KEY
         // bug 11238: pass on the target
         wn = WGEN_Expand_Expr (gs_tree_operand (exp, 1), need_result,
-                               0, 0, 0, 0, FALSE, FALSE, target_wn);
+                               nop_ty_idx, component_ty_idx,
component_offset,
+                               field_id, is_bit_field,
is_aggr_init_via_ctor, target_wn);
 #else
         wn = WGEN_Expand_Expr (gs_tree_operand (exp, 1), need_result);
 #endif
------------------------------------------------------------------------------
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