public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Seongbae Park (박성배, 朴成培)" <seongbae.park@gmail.com>
To: "Nathan Sidwell" <nathan@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	"Janis Johnson" <janis187@us.ibm.com>,
	 	mark@codesourcery.com
Subject: Re: [PATCH] Wrong coverage attribution.
Date: Tue, 31 Jul 2007 18:20:00 -0000	[thread overview]
Message-ID: <ab3a61990707311052m79b50b92ta6766de2c068173a@mail.gmail.com> (raw)
In-Reply-To: <ab3a61990707310833s43f66f55h6ae0bb1bf9062962@mail.gmail.com>

On 7/31/07, Seongbae Park (박성배, 朴成培) <seongbae.park@gmail.com> wrote:
> On 7/30/07, Nathan Sidwell <nathan@codesourcery.com> wrote:
> > Seongbae Park (???, ???) wrote:
> > > *ping*
> >
> > >> Attached patch fixes the problem shown in the testcase
> > >> - this testcase fails in the current mainline
> > >> because of GOTO moved to a different block during eh lowering.
> >
> > Sorry, I thought I'd emailed you about this, but I find no record of that.
> > Could you explain in more detail what the problem is and why your patch is correct?
>
> Sure.
>
> Given the new testcase included in the patch:
>
>      26   if (i == 1) {
>      27     f.method();
>      28     f.method();
>      29   } else {
>      30     f.method();
>      31     printf("unreachable\n");
>      32     return 2;        /* count(#####) */
>      33   }
>      34   f.method();
>      35   return 0;
>      36 }
>
> we get the following tree at the end of lowering (and before tree-eh):
>
>   [gcov-4.C : 35] try
>     {
>       [gcov-4.C : 26] if (i == 1) goto <D2786>; else goto <D2787>;
>       <D2786>:;
>       [gcov-4.C : 27] method (&f);
>       [gcov-4.C : 28] method (&f);
>       goto <D2788>;
>       <D2787>:;
>       [gcov-4.C : 30] method (&f);
>       [gcov-4.C : 31] __builtin_puts (&"unreachable"[0]);
>       [gcov-4.C : 32] D.2776 = 2;
>       [gcov-4.C : 32] goto <D2783>;
>       <D2788>:;
>       [gcov-4.C : 34] method (&f);
>       [gcov-4.C : 35] D.2776 = 0;
>       [gcov-4.C : 35] goto <D2783>;
>     }
>   finally
>     {
>       [gcov-4.C : 35] __comp_dtor  (&f);
>     }
>   <D2783>:;
>   return D.2776;
>
> After tree-eh (with the patch, without patch,
> GOTO D2783 in block D2789 would have the line no 32):
>
>   [gcov-4.C : 26] if (i == 1) goto <D2786>; else goto <D2787>;
>   <D2786>:;
>   [gcov-4.C : 27] method (&f);
>   [gcov-4.C : 28] method (&f);
>   goto <D2788>;
>   <D2787>:;
>   [gcov-4.C : 30] method (&f);
>   [gcov-4.C : 31] __builtin_puts (&"unreachable"[0]);
>   [gcov-4.C : 32] D.2776 = 2;
>   goto <D2789>;
>   <D2788>:;
>   [gcov-4.C : 34] method (&f);
>   [gcov-4.C : 35] D.2776 = 0;
>   goto <D2789>;
>   <D2789>:;
>   [gcov-4.C : 35] __comp_dtor  (&f);
>   goto <D2783>;
>   <D2783>:;
>   return D.2776;

I just realized that I haven't explained things in enough detail:

> lower_try_finally_onedest() is called only when try-finally
> has only one destination for the finally.
> During lower_try_finally_onedest(), among all collected goto's
> to the common destination of finally,
> we arbitrarily pick the first GOTO and append it to the finally block.

By the first goto, I meant

       [gcov-4.C : 32] goto <D2783>;

in block D2787 before tree-eh. This GOTO and all other
GOTOs that go to D2783 within try region are removed by
do_goto_redirection() call within lower_try_finally_onedest(),
and then the first one among removed GOTOs is append
to the end of the finally block.

> Obviously,  the original GOTO for line 32 doesn't belong to the finally block,
> hence the fix.

Without the fix, because the problematic GOTO is now moved to
the end of the finally block, it gets executed always,
unlike the original GOTO. This gives us the wrong coverage result
because the line that GOTO belongs to shouldn't be shown as executed.
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"

  reply	other threads:[~2007-07-31 17:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-26 23:35 Seongbae Park (박성배, 朴成培)
2007-07-30 18:34 ` Seongbae Park (박성배, 朴成培)
2007-07-31  3:52   ` Nathan Sidwell
2007-07-31 15:44     ` Seongbae Park (박성배, 朴成培)
2007-07-31 18:20       ` Seongbae Park (박성배, 朴成培) [this message]
2007-08-09  4:41   ` Seongbae Park (박성배, 朴成培)
2007-08-15 23:12     ` Seongbae Park (박성배, 朴成培)
2007-07-30 19:12 ` Janis Johnson
2007-08-16  1:35 ` Diego Novillo
2007-08-16 17:30   ` Seongbae Park (박성배, 朴成培)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab3a61990707311052m79b50b92ta6766de2c068173a@mail.gmail.com \
    --to=seongbae.park@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=janis187@us.ibm.com \
    --cc=mark@codesourcery.com \
    --cc=nathan@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).