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
