running correct means nothing to me. you are fixing the optimizer
trace of dce and htable

On Sat, Dec 17, 2011 at 5:23 PM, Gang Yu <yugang...@gmail.com> wrote:

> I can confirm this is the right fix. I have tested all the test cases on
> bug897, no doubltly right.
>
> So, what traces do you want?
>
> Regards
> Gang
>
>
>  On Sat, Dec 17, 2011 at 5:22 PM, Sun Chan <sun.c...@gmail.com> wrote:
>
>> I highly doubt you have the right fix. OTOH, I can't follow your
>> explaination either. Can you further cut down the example? Also, try to use
>> something less confusing in names because it gets mixed up with versioning
>> of stmt, symbol etc.
>> Once you have a minimum case, we can look at some trace first
>> Sun
>>
>>  On Sat, Dec 17, 2011 at 5:11 PM, Gang Yu <yugang...@gmail.com> wrote:
>>
>>>  Hi,
>>>
>>>    Could a gatekeeper please help review the fix for bug897(
>>> https://bugs.open64.net/show_bug.cgi?id=897)?
>>>
>>> when we use csmith to test the compiler stability, we find the DCE
>>> always trapped into segment fault.
>>>
>>> A typical case:
>>> int32_t g_46 = 0L;
>>> int32_t g_71 = 0L;
>>> int32_t *g_311 = &g_46;
>>> int32_t * func_19(int32_t * p_20, int16_t p_21, int32_t * p_22, const
>>> uint8_t
>>> p_23, int32_t * p_24) {
>>>   int32_t **l_426 = &g_311;
>>>   const uint64_t l_440 = 0x2A1DFCF9L;
>>>   for (p_21 = (-24);
>>>           (p_21 < 1);
>>>           p_21 = safe_add_func_int16_t_s_s(p_21, 3)) {
>>>         int32_t ***l_428 = &l_426;
>>>         (*l_428) = &g_311;
>>>         if ((*p_20)) {
>>>           if (l_440) {
>>>           }
>>>           else {
>>>                 uint32_t l_445 = 4U;
>>>                 if ((*g_311)) {
>>>                   if ((safe_rshift_func_uint16_t_u_s(func_124((&p_22 !=
>>> &p_24)), 10))) {
>>>                         (*g_311) |= l_445;
>>>                         (**l_426) |= (*p_24);
>>>                         g_311 = &g_71;
>>>                   }
>>>                 }
>>>           }
>>>         }
>>>   }
>>> }
>>> Analysis:
>>>
>>> the segment fault always occurs at the dead_store_elim phase of DCE,
>>> i.e, after the Unreachable_code_elim, and the backtrace shows the DCE tries
>>> to mark call statement func_124 live, this is a wrong operation.  the
>>> branch
>>>           else {
>>> uint32_t l_445 = 4U;
>>> if ((*g_311)) {
>>> if ((safe_rshift_func_uint16_t_u_s(func_124((&p_22 !=
>>> &p_24)), 10))) {
>>> (*g_311) |= l_445;
>>> (**l_426) |= (*p_24);
>>> g_311 = &g_71;
>>> }
>>> }
>>> }
>>> has already been deleted by DCE at this point, more investigation shows,
>>> when mark safe_add_func_int16_t_s_s(p_21, 3) live, DCE will also mark the
>>> mu node g_311 live, which then marks the sym10v0(g_311) version live.
>>> The sym10v0 is resurrected chi to (*g311) |= l_445, so (*g_311) |= l_445
>>> should be marked live(at this case it should already been marked live
>>> although removed[in deleted block]). However it is not the case, DCE tries
>>> to mark that statement live...
>>>
>>> the problem is we do unexpected at Remove_stmtrep:
>>> 720// remove the given statement from this block
>>> 721void
>>> 722BB_NODE::Remove_stmtrep( STMTREP *stmt )
>>> 723{
>>> ...
>>> 735  _stmtlist.Remove(stmt);
>>> 736  stmt->Reset_live_stmt();  // WHIRL SSA: mark stmt dead
>>> 737}
>>>
>>> 736 is the cause of this fault.
>>>
>>> Suggested fix:
>>> --- a/osprey/be/opt/opt_bb.cxx
>>> +++ b/osprey/be/opt/opt_bb.cxx
>>> @@ -733,7 +733,6 @@ BB_NODE::Remove_stmtrep( STMTREP *stmt )
>>>    }
>>>    _stmtlist.Remove(stmt);
>>> -  stmt->Reset_live_stmt();  // WHIRL SSA: mark stmt dead
>>>  }
>>>
>>>
>>> Regards
>>> Gang
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
>>> Microsoft is holding a special Learn Windows Azure training event for
>>> developers. It will provide a great way to learn Windows Azure and what
>>> it
>>> provides. You can attend the event by watching it streamed LIVE online.
>>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>>
>>
>
------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to