branches within C++ destructors (gcov)

[Rohit Gupta]

HI all,

  I have another query related to virtual destructor in gcc.
In present gcc version 4.4.3 for class for sample program:-
------------------------
class A
{
public:
         A()
         {
         }

         virtual ~A();
};
         A::~A()
         {
         }

int main(int argc, char ** argv)
{

         A a;

         return 0;
}
--------------------------
we have only two branches as:-
-------------------------------------------------------
        -:    8:        virtual ~A();
         -:    9:};
function A::~A() called 1 returned 100% blocks executed 75%
function A::~A() called 0 returned 0% blocks executed 0%
         1:   10:        A::~A()
         -:   11:        {
         1:   12:        }
branch  0 taken 0% (fallthrough)
branch  1 taken 100%
call    2 never executed
call    3 never executed
call    4 never executed
------------------------------------------------------------------
which I has interpreted as :
In virtual destructor there are actually two destructors in which one 
takes care about base classes and other about the same class.So to have 
two branches looks OK

But for same program the result are different in gcc version 4.1.2.The 
result contains 6 branches and the output is as :

----------------
8:        virtual ~A();
         -:    9:};
function A::~A() called 0 returned 0% blocks executed 0%
function A::~A() called 1 returned 100% blocks executed 75%
function A::~A() called 0 returned 0% blocks executed 0%
         1:   10:        A::~A()
         -:   11:        {
         1:   12:        }
branch  0 never executed
branch  1 never executed
call    2 never executed
branch  3 taken 0% (fallthrough)
branch  4 taken 100%
call    5 never executed
branch  6 never executed
branch  7 never executed
call    8 never executed
         -:   13
---------------
Can someone tell me the logic about these branches and what  optimizer 
improvements were done in newer version.

--
Thanks ,
ROHIT

On 02/25/2010 01:59 PM, Rohit Gupta wrote:
> Hi ,
> Also in the gcov branch coverage we have something like at end of code :-
>
> ------------------------------------
>
> function __static_initialization_and_destruction_0(int, int) called 1 
> returned 100% blocks executed 100%
> function global constructors keyed to main called 1 returned 100% 
> blocks executed 100%
>         3:   54:}
> branch  0 taken 100% (fallthrough)
> branch  1 taken 0%
> branch  2 taken 100% (fallthrough)
> branch  3 taken 0%
> call    4 returned 100%
> ------------------------------------------------
>
>
> It is not the part of actual code, why do we have it and what its 
> significance in terms of branches . Can we omit it from the coverage??
>
> Thanks,
> ROHIT
>
>
> On 02/18/2010 08:14 PM, Axel Freyn wrote:
>> Hi,
>>
>> On Thu, Feb 18, 2010 at 03:52:28PM +0530, Rohit Gupta wrote:
>>> [...]
>>> I am having problem understanding branches ( number ) generated by
>>> gcov  report for c++ program. Might you please clear my doubts.
>> I fear there is no such possibility, as
>> http://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html states:
>>
>> "There can be multiple branches and calls listed for a single source
>> line if there are multiple basic blocks that end on that line. In this
>> case, the branches and calls are each given a number."
>>
>> and
>>
>> "There is no simple way to map these branches and calls back to source
>> constructs. In general, though, the lowest numbered branch or call will
>> correspond to the leftmost construct on the source line. "
>>
>>
>> In addition, the compiler seems to use its internal representation to
>> define the "calls" and "branches", e.g. at the end of main gcov states:
>>
>>> function __static_initialization_and_destruction_0(int, int) called 
>>> 1 returned 100% blocks executed 100%
>>> function global constructors keyed to main called 1 returned 100% 
>>> blocks executed 100%
>>>          3:   54:}
>> thus calling two functions which you never called (but which are called
>> by the system). So I think, in order to fully understand the output 
>> of gcov,
>> you would have to look at the internal way how the compiler constructs
>> the code.
>>
>> HTH,
>>
>> Axel
>>
>>
>