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