Bug 12076 - gcov misreports coverage of return statement [NRV]
Summary: gcov misreports coverage of return statement [NRV]
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 23052 31810 42660 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-08-27 09:34 UTC by Robert Lichtenberger
Modified: 2016-01-14 18:11 UTC (History)
9 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-09-04 19:01:30


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Lichtenberger 2003-08-27 09:34:15 UTC
I compiled & ran this little program:
#include <string>
#include <iostream>

std::string repeat(const std::string& p_str, unsigned int p_count)
{
    std::string result;
    for (unsigned int i=0;i<p_count;++i)
        result+=p_str;
    return result;
}

int main(void)
{
        std::cout << repeat("gnu", 20) << std::endl;

        return 0;
}

The line containing the return statement is marked as "not run", which cannot be:
                std::string repeat(const std::string& p_str, unsigned int p_count)
           1    {
           1        std::string result;
          21        for (unsigned int i=0;i<p_count;++i)
          20            result+=p_str;
      ######        return result;
                }
Comment 1 Wolfgang Bangerth 2003-08-27 14:04:59 UTC
Confirmed up to present mainline. 
W. 
Comment 2 Andrew Pinski 2003-11-28 08:02:25 UTC
The problem at -O3, gcc inlines more functions and in this case repeat is inlined so the 
return is misreported because really is not executed at all (it is a no-op).  I  going to say 
this is a non-bug because it really is not executed.
Comment 3 Robert Lichtenberger 2003-11-28 09:11:06 UTC
But the problem also occurs when using -O0 (no optimization). Here is how I
compiled:
[tanis@icotanis new]$ g++ -fprofile-arcs -ftest-coverage -O0 covtest.cc 

With -O0, the compiler should not inline, should it?
Comment 4 Andrew Pinski 2003-11-28 17:47:44 UTC
I can confirm this at -O0 but it works correctly at -O1.
Comment 5 Robert Lichtenberger 2003-12-01 06:27:05 UTC
Which version did you use? With this version:
  [tanis@icotanis new]$ g++ --version
  g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

-O1 is no different. 

Comment 6 Andrew Pinski 2003-12-01 06:33:04 UTC
The mainline (3.4 20031108).
Comment 7 Andrew Pinski 2003-12-26 23:01:15 UTC
Very much related to bug 11773.
Comment 8 Andrew Pinski 2004-05-20 20:23:33 UTC
Actually this has to do with deconstrutors so I do not think this is a bug.
Comment 9 Andrew Pinski 2004-08-13 00:04:10 UTC
I know what the bug is really, it has to do with NVR optimization in GCC which allows the return value 
to at the same location as result.
Comment 10 Andrew Pinski 2005-07-25 01:43:26 UTC
*** Bug 23052 has been marked as a duplicate of this bug. ***
Comment 11 Joe Buck 2005-07-25 20:54:03 UTC
It's OK if NVR uses the same location and emits no code, and if coverage
information reflects this.  The problem is that part of the coverage machinery
appears to "think" that there is unreached code on the line with the return
statement, so a "#####" is output rather than a "-".  Emitting a "-" rather
than a count would also be OK, and arguably correct if there is no real object
code corresponding to the source line.



Comment 12 Martin Reddy 2005-10-27 01:41:25 UTC
Having code coverage emit a "-" instead of "#####" in this case sounds appropriate and would certainly solve the problem for me.

Is there a way to workaround this issue by reorganizing code, or something else, so that I can fool the NVR smarts into not getting invoked in this particular case?
Comment 13 jbuck@welsh-buck.org 2006-01-21 22:33:19 UTC
Subject: Re:  gcov misreports coverage of return statement
	[NVR]

On Thu, 2005-10-27 at 01:41 +0000, reddy at pixar dot com wrote:
> 
> ------- Comment #12 from reddy at pixar dot com  2005-10-27 01:41 -------
> Having code coverage emit a "-" instead of "#####" in this case sounds
> appropriate and would certainly solve the problem for me.
> 
> Is there a way to workaround this issue by reorganizing code, or something
> else, so that I can fool the NVR smarts into not getting invoked in this
> particular case?

The -fno-elide-constructors flag helps; it forces explicit copy constructor
calls, and that seems to get rid of most of the bogons -- but apparently
not all of them -- I'll look further, but I think sometimes the
initializer for a base class gets optimized in a way that results in a
false ###### flagging.  Still, if you're having this trouble, start with
that flag.


Comment 14 Andrew Pinski 2007-05-04 02:34:13 UTC
*** Bug 31810 has been marked as a duplicate of this bug. ***
Comment 15 Jan Hubicka 2007-05-06 15:31:57 UTC
The problem with NRV transformation is that it removes the return statement from default path and keeps it in the catch path making GCOV to properly output it as unexecuted.  I tried to look into the NRV modify_expr withing return_expr but it is not the place to find the proper locator, looks like NRV itself needs to be updated.

Honza
Comment 16 Joe Buck 2007-05-07 00:32:42 UTC
The return statement, before the optimization, does two things; it causes a copy constructor call, and it causes the function to return.  NVR eliminates the copy constructor call, but the statement still returns.  At -O0, don't we still hit a distinct return statement for the code at the given source line?  The fact that there is also unexecuted code present that executes only if exceptions are caught should not matter, because we mark a statement as covered if any part of it executes.
Comment 17 Andrew Pinski 2010-01-08 17:46:09 UTC
*** Bug 42660 has been marked as a duplicate of this bug. ***
Comment 18 Paul Robinson 2012-04-27 13:37:30 UTC
Is this ever going to be looked at? It makes most gcov output incorrect and hence not useful.
Comment 19 Paolo Carlini 2012-08-20 22:49:26 UTC
I understand this is still an issue. Let's add Jason in CC, IIRC he contributed the NRV optimization on trees.