I had not much of experience with the WGEN code. Judging from the bug description and your fix, it seemed this is the right and better fix. Zqing, can you pls try this fix since Stephen isn't sure this is the only change needed? Thx! Sun
2011/8/26 Stephen Clarke <stephen.cla...@st.com>: > Here we appear to have a different and simpler fix for the failing > case. It avoids recursing into WGEN_Expand_Expr which corrupts the > initializer. > > Unfortunately we have several other changes in this area, and > I cannot immediately say for sure if that change works standalone or > if it requires something else. > > Steve. > > $ diff -u wgen_decl.cxx.orig wgen_decl.cxx > --- wgen_decl.cxx.orig 2011-08-26 13:14:00.242892000 +0100 > +++ wgen_decl.cxx 2011-08-26 13:38:00.459860000 +0100 > @@ -2578,21 +2578,9 @@ > case GS_NOP_EXPR: > gs_t kid; > kid = gs_tree_operand(val,0); > - if (gs_tree_code(kid) == GS_ADDR_EXPR && > - /* bug fix for OSP_279 */ > - gs_tree_code(gs_tree_operand(kid,0)) == GS_STRING_CST) > - { > - kid = gs_tree_operand(kid,0); > - WGEN_Add_Aggregate_Init_Address (kid); > - break; > - } > - else > - if (gs_tree_code(kid) == GS_INTEGER_CST) { > - WGEN_Add_Aggregate_Init_Integer ( > - gs_get_integer_value(kid), size); > - break; > - } > - // fallthru > + // [SC] NOP_EXPR does not change representation, so just > recurse on kid. > + Add_Initv_For_Tree (kid, size); > + break; > default: > { > WN *init_wn; > > > > 朱庆 wrote: >> Hi all, >> Can gatekeeper help review following fix for bug833? >> https://bugs.open64.net/show_bug.cgi?id=833 >> case: >> struct in6_addr >> { >> unsigned char u6_addr8[16]; >> }; >> >> static const struct ip6addrlbl_init_table >> { >> const struct in6_addr *prefix; >> int prefixlen; >> } array_table = >> { >> .prefix = &(struct in6_addr){ 0xfc }, >> .prefixlen = 7, >> }; >> int main() >> { >> printf("%x\n",*array_table.prefix); >> } >> The result should be 0xfc, but not Segmentation fault. >> The problem is the initial for array_table is incorrect. >> The creation of inito and initv is sequently, if there is an initial >> in another initial, and need to set up a new st , the initv index is >> increased in the new st initialize, when return from the new init_wn, >> we should adjust the block index of the uplevel inito. >> >> ======================================================================= >> INITOs: >> [1]: array_table (0x3501): >> BLOCK: >> BLOCK: ==> >> BLOCK: ==> >> VAL: 252 ===> SYMOFF: .init(0x3601)+0(0x0) >> PAD: 15 ==> VAL: 7 >> ENDBLOCK=> PAD: 4 >> ENDBLOCK==> >> ENDBLOCK >> [2]: .init (0x3601): >> BLOCK: >> BLOCK: >> VAL: 252 >> PAD: 15 >> ENDBLOCK >> ENDBLOCK >> >> patch: >> Index: osprey/wgen/wgen_decl.cxx >> =================================================================== >> --- osprey/wgen/wgen_decl.cxx (revision 3714) >> +++ osprey/wgen/wgen_decl.cxx (working copy) >> @@ -2622,7 +2622,19 @@ >> WGEN_Get_LABEL (label_decl, FALSE); >> WGEN_Add_Aggregate_Init_Label (label_idx); >> } >> - else Add_Init_For_WHIRL(init_wn, size, 0); >> + else { >> + Add_Init_For_WHIRL(init_wn, size, 0); >> + if (WN_has_sym(init_wn)) { >> + ST* st = WN_st(init_wn); >> + INITO_IDX idx = Find_INITO_For_Symbol(st); >> + if (idx != 0 && >> + ST_initv_in_other_st(st) && >> + idx > _inito ) { >> + INITO ino = Inito_Table[idx]; >> + Set_INITV_blk(ino.val-1, _last_initv); >> + } >> + } >> + } >> WN_DELETE_Tree (init_wn); >> break; >> } >> >> >> Thanks >> zhuqing >> >> ------------------------------------------------------------------------------ >> EMC VNX: the world's simplest storage, starting under $10K >> The only unified storage solution that offers unified management >> Up to 160% more powerful than alternatives and 25% more efficient. >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel > > > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel