[Bug gcov-profile/64634] New: gcov reports catch(...) as not executed

[Bug gcov-profile/64634] New: gcov reports catch(...) as not executed

[joerg.richter@pdv-fs.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

            Bug ID: 64634
           Summary: gcov reports catch(...) as not executed
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joerg.richter@pdv-fs.de

cat > t.cc <<EOF
#include <cstdlib>
void catchEx()
{
  exit(0);
  try
  {}
  catch( int )
  {}
}

int main()
{
  try
  {
    throw 5;
  }
  catch(...)
  {
    catchEx();
  }
}
EOF

g++ -o t t.cc -O0 --coverage -g
./t

-----

If you now call gcov like this:
gcov -b t.gcda

t.cc.gcov looks like this:

...
    =====:   18:  catch(...)
call    0 never executed
call    1 never executed
call    2 returned 100%
call    3 never executed
...

But if you call gcov like this:
gcov -a -b t.gcda
Then t.cc.gcov looks like this:

...
        1:   18:  catch(...)
    %%%%%:   18-block  0
call    0 never executed
call    1 never executed
    1:   18-block  1
    1:   18-block  2
call    2 returned 100%
    %%%%%:   18-block  3
call    3 never executed
...

Note that in the former case the catch(...) on line 18 is 
marked as not executed and in the later it is marked as 
executed. This results in wrong coverage information.

Calling gcov always with -a is no option for us. Because
gcov -a is much slower.

Works with GCC 4.4.4.  Fails since 4.5.

[Bug gcov-profile/64634] [4.8/4.9/5 Regression] gcov reports catch(...) as not executed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-19
      Known to work|                            |4.4.7
   Target Milestone|---                         |4.8.5
            Summary|gcov reports catch(...) as  |[4.8/4.9/5 Regression] gcov
                   |not executed                |reports catch(...) as not
                   |                            |executed
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.2

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug gcov-profile/64634] [4.8/4.9/5 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r151696, if for coverage the sequentially first bb with particular
lineno matters, then indeed emitting:
  [pr64434.C : 14:12] D.2096 = __cxa_allocate_exception (4);
  [pr64434.C : 14:12] D.2098 = (int *) D.2096;
  [pr64434.C : 14:12] *D.2098 = 5;
  [pr64434.C : 14:11] __cxa_throw (D.2096, &_ZTIi, 0B);
  <D.2104>:
  [pr64434.C : 0:0] D.2100 = 0;
  [pr64434.C : 0:0] goto <D.2101>;
  <D.2101>:
  return D.2100;
  <D.2102>:
  [pr64434.C : 16:9] __cxa_end_catch ();
  resx 2
  <D.2105>:
  eh_dispatch 1
  resx 1
  <D.2103>:
  [pr64434.C : 16:9] D.2099 = __builtin_eh_pointer (1);
  [pr64434.C : 16:9] __cxa_begin_catch (D.2099);
  [pr64434.C : 18:14] catchEx ();
  [pr64434.C : 16:9] __cxa_end_catch ();
  goto <D.2104>;
means the first bb with lineno 16 is __cxa_end_catch, while in r151695 we
emitted:
  [pr64434.C : 14:12] D.2093 = __cxa_allocate_exception (4);
  [pr64434.C : 14:12] D.2095 = (int *) D.2093;
  [pr64434.C : 14:12] *D.2095 = 5;
  [pr64434.C : 14:11] __cxa_throw (D.2093, &_ZTIi, 0B);
  <D.2104>:
  [pr64434.C : 16:9] __cxa_begin_catch ([pr64434.C : 16] <<<exception
object>>>);
  [pr64434.C : 18:14] catchEx ();
  goto <D.2103>;
  <D.2098>:
  save_filt.1 = [filter_expr] <<<filter object>>>;
  save_eptr.0 = [exc_ptr_expr] <<<exception object>>>;
  [pr64434.C : 16:9] __cxa_end_catch ();
  <<<exception object>>> = save_eptr.0;
  <<<filter object>>> = save_filt.1;
  resx 3
  <D.2101>:
  std::terminate ();
  <D.2103>:
  [pr64434.C : 16:9] __cxa_end_catch ();
  goto <D.2105>;
  <D.2105>:
  [pr64434.C : 0:0] D.2096 = 0;
  [pr64434.C : 0:0] goto <D.2097>;
  <D.2097>:
  return D.2096;

[Bug gcov-profile/64634] [4.8/4.9/5 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34802&action=edit
gcc5-pr64634.patch

Untested fix.

[Bug gcov-profile/64634] [4.8/4.9/5 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Feb 18 22:02:43 2015
New Revision: 220801

URL: https://gcc.gnu.org/viewcvs?rev=220801&root=gcc&view=rev
Log:
    PR gcov-profile/64634
    * tree-eh.c (frob_into_branch_around): Fix up typos
    in function comment.
    (lower_catch): Put eh_seq resulting from EH lowering of
    the cleanup sequence after the cleanup rather than before
    it.

    * g++.dg/gcov/gcov-15.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/gcov/gcov-15.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-eh.c

[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.0
            Summary|[4.8/4.9/5 Regression] gcov |[4.8/4.9 Regression] gcov
                   |reports catch(...) as not   |reports catch(...) as not
                   |executed                    |executed

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed

[joerg.richter@pdv-fs.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

--- Comment #6 from Jörg Richter <joerg.richter@pdv-fs.de> ---
Is this stable enough to be considered for 4.9.3?
>From gcc-bugs-return-480516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 17 08:51:25 2015
Return-Path: <gcc-bugs-return-480516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 98599 invoked by alias); 17 Mar 2015 08:51:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 98540 invoked by uid 48); 17 Mar 2015 08:51:21 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65446] New: Improve -Wformat-signedness
Date: Tue, 17 Mar 2015 08:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-65446-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01660.txt.bz2
Content-length: 1507

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide446

            Bug ID: 65446
           Summary: Improve -Wformat-signedness
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

As PR 65040 shows, the current implementation of -Wformat-signedness is not
optimal. (When it is more robust, one could consider to re-enable it with
-Wformat=2.)

The idea of the warning is to warn for
   "%ld",   size_t_variable
as one has to use "%lu" to print the negative values. Or reversely using %u for
a signed value, where it is even more likely that the issue occurs.

See also "cppcheck --enable=warning" which supports this warning. (But its
warning pattern makes more sense than GCC's.)


GCC's current implementation warns too often - and misses some cases. The main
bug is that it doesn't take type promotion into account. In particular:

It warns for:
   printf ("%u\n", unsigned_short);
but shouldn't: First, %u and unsigned_short are both unsigned. (It also
shouldn't and doesn't warn for %d with unsigned short as all values are
representible by %d.

It doesn't warn but should warn for
   printf("%u\n", _short);

As passing, e.g., (short)-1 to %u will print the wrong value (UINT_MAX instead
of -1).


GCC currently also warns for printf("%x\n", 1), which is very questionable.

[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jun  3 21:33:22 2015
New Revision: 224102

URL: https://gcc.gnu.org/viewcvs?rev=224102&root=gcc&view=rev
Log:
        Backported from mainline
        2015-02-18  Jakub Jelinek  <jakub@redhat.com>

        PR gcov-profile/64634
        * tree-eh.c (frob_into_branch_around): Fix up typos
        in function comment.
        (lower_catch): Put eh_seq resulting from EH lowering of
        the cleanup sequence after the cleanup rather than before
        it.

        * g++.dg/gcov/gcov-15.C: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/g++.dg/gcov/gcov-15.C
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-eh.c

[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now in 4.8+.