If you have tested that, pls go ahead
Sun
2011/8/29 朱庆 <zqing1...@gmail.com>:
> The new patch works well with the small and even larger cases. I am ok with
> it.
>
> Hi Steve,
> Thank you for providing the patch. Do you need me to follow up the
> checkin after Sun approved?
>
> Thanks
> zhuqing
>
> 在 2011年8月26日 下午9:23，Sun Chan <sun.c...@gmail.com> 写道：
>> 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
