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
