There might be some potential WN node leaks in this function but I think we
can live with it since the memory is managed by the pool.
Any other comments?
在 2010年8月31日 下午4:16，Mike Murphy <mmur...@nvidia.com>写道：
> I'm leaving for vacation and don't have time to review this till next
> week. Maybe another gatekeeper could review it?
>
> ------------------------------
> *From:* 朱庆 [mailto:zqing1...@gmail.com]
> *Sent:* Tuesday, August 31, 2010 12:57 AM
>
> *To:* Mike Murphy
> *Cc:* open64-devel@lists.sourceforge.net
> *Subject:* Re: [Open64-devel] Assertion failure in wn_lower phase
>
> New patch with your advice, just delete when replace those nodes.
>
> Index: wn_lower.cxx
> ===================================================================
> --- wn_lower.cxx (revision 3327)
> +++ wn_lower.cxx (working copy)
> @@ -2400,8 +2400,6 @@
> WN_Sqrt(desc, WN_kid0(tree)));
>
> lower_complex_expr(block, div, actions, realpart, imagpart);
> -
> - WN_Delete(tree);
> }
> break;
>
> @@ -2416,7 +2414,6 @@
>
> *realpart = WN_Paren(type, *realpart);
> *imagpart = WN_Paren(type, *imagpart);
> - WN_Delete(tree);
> }
> break;
>
> @@ -2589,7 +2586,6 @@
> *realpart = WN_LdidPreg(type, realpartN);
> *imagpart = WN_LdidPreg(type, imagpartN);
> }
> - WN_Delete(tree);
> }
> break;
>
> @@ -2817,7 +2813,6 @@
> *realpart = WN_LdidPreg(type, realpartN);
> *imagpart = WN_LdidPreg(type, imagpartN);
> }
> - WN_Delete(tree);
> }
> break;
>
> @@ -2846,8 +2841,6 @@
> realpart, &iz);
>
> *imagpart = WN_Neg(type, iz);
> -
> - WN_Delete(tree);
> }
> break;
> case INTRN_V16C8MPY_ADDSUB:
> @@ -8041,6 +8034,7 @@
> if (imagexp == NULL && realTY == WN_rtype(WN_kid0(tree)))
> {
> imagexp = WN_Floatconst(realTY, 0.0);
> + WN_Delete(WN_kid0(tree));
> WN_kid0(tree) = WN_CreateExp2( OPR_PAIR, WN_desc(tree), MTYPE_V,
> realexp, imagexp);
> }
> @@ -8467,7 +8461,7 @@
> eval = WN_CreateEval(realexp);
> WN_Set_Linenum(eval, current_srcpos); // Bug 1268
> WN_INSERT_BlockLast(block, eval);
> -
> + WN_Delete(child);
> child = imagexp;
> }
> else if (Action(LOWER_QUAD) && MTYPE_is_quad(WN_rtype(child)))
>
> ---------
> Thanks,
> zhuqing
>
> 在 2010年8月27日 上午7:33，Mike Murphy <mmur...@nvidia.com>写道：
>
>> In several places you do
>> WN_kid0(tree) ==NULL;
>> which is one too many =.
>>
>> The code around the original problem looks wrong too, as if you move
>> lower_complex_expr down, then line 8041 which references imageexp is wrong.
>>
>> The usual rule is that the when you replace a node you should delete. To
>> always delete the node after every call seems potentially wrong, if the node
>> was still referenced (admittedly not the common case). The code for
>> this lower_complex_expr does not seem consistent which is confusing and thus
>> is causing the problem you are seeing. It looks to me like
>> lower_complex_expr should not be doing any deletes, but I wouldn't
>> automatically do the deletes after every call. It does look like lines 8044
>> and 8088 should be deletes, plus 8465.
>>
>> ------------------------------
>> *From:* 朱庆 [mailto:zqing1...@gmail.com]
>> *Sent:* Wednesday, August 25, 2010 7:38 PM
>> *To:* Mike Murphy
>> *Cc:* open64-devel@lists.sourceforge.net
>> *Subject:* Re: [Open64-devel] Assertion failure in wn_lower phase
>>
>> Yes, you are right, I 've added the new patch in the attchment to
>> deleted all the whirl node after they were lowered. Could you help reviewing
>> it again?
>>
>> Thanks,
>> Zhuqing
>>
>> 在 2010年8月19日 下午1:07，Mike Murphy <mmur...@nvidia.com>写道：
>>
>>> Aren't there multiple calls to lower_complex_expr? In this case maybe
>>> only deleting at the caller is right, but if other uses do not do the
>>> delete, and you don't delete in the callee, then you will never delete.
>>>
>>> ------------------------------
>>> *From:* 朱庆 [mailto:zqing1...@gmail.com]
>>> *Sent:* Wednesday, August 18, 2010 9:23 PM
>>> *To:* open64-devel@lists.sourceforge.net
>>> *Subject:* [Open64-devel] Assertion failure in wn_lower phase
>>>
>>> Hi, All
>>>
>>> Can gatekeeper help review this fix?
>>>
>>> This bug is happens in wn_lower phase, more detailed info please refer to
>>> https://bugs.open64.net/show_bug.cgi?id=591.
>>> Attached is the patch.
>>>
>>> The failure is due to one whirl node address attached by two nodes.
>>> The main cause is that in wn_lower.cxx:7741:lower_complex_expr(block,
>>> WN_kid0(tree), actions, &realexp, &imagexp), WN_kid0(tree) was deleted in
>>> the function,
>>> , howerver in 7783, the node deleted again , so if there are other new
>>> node created between line 7741and 7783, it may reuse the deleted node
>>> address, and will be wrongly deleted by line 7783.
>>> The fix is modified function lower_complex_expr, delete all
>>> "WN_Delete(tree);".
>>>
>>> 7741 lower_complex_expr(block, WN_kid0(tree), actions, &realexp,
>>> &imagexp);
>>> 7742 ......
>>> 7762 realexpN = AssignExpr(block, realexp, realTY);
>>> 7763 realexp_copy = WN_LdidPreg(realTY, realexpN);
>>> 7764 .......
>>> 7783 WN_Delete(WN_kid0(tree));
>>> 7784 WN_kid0(tree) = WN_Ldid(MTYPE_F8, 0, c4temp_st,
>>> MTYPE_To_TY(MTYPE_F8));
>>>
>>>
>>> Best Regards,
>>> Zhu Qing
>>> ------------------------------
>>> This email message is for the sole use of the intended recipient(s) and
>>> may contain confidential information. Any unauthorized review, use,
>>> disclosure or distribution is prohibited. If you are not the intended
>>> recipient, please contact the sender by reply email and destroy all copies
>>> of the original message.
>>> ------------------------------
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
