you are suppose to convince me your fix is correct. You are turning it
around?
I need traces and min test case to be convinced, pls supply that
Sun
On Sat, Dec 17, 2011 at 5:31 PM, Gang Yu <yugang...@gmail.com> wrote:
> On the fix its own, what is your doubt? What do you think is illogical?
>
> Regards
> Gang
>
>
> On Sat, Dec 17, 2011 at 5:28 PM, Sun Chan <sun.c...@gmail.com> wrote:
>
>> 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
