function coverage not hit, then line coverage hit

[yangsee0]

Hello. There are some unusual phenomena, so I want to consult. There was a function call, but the function introduction part is not covered, and the inside of the function is covered. Is this normal? Please help me how to solve it. Thank you very much for your confirmation.

g++ (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20) lcov 2.0.1

  52                 :           0 : static uint32_t check(uint32_t id, Down_t* MC)
  53                 :             : {
  54                 :             :     uint32_t list;
  55                 :             : 
  56   [ +  +  #  # ]:          31 :     if((MC->Cnt == 0) || (MC->Cnt > MAX_B))
  57                 :             :     {
  58                 :             :         return TRUE;
  59                 :             :     }
  60                 :             : 
  61   [ +  +  #  # ]:          16 :     for(list = 1; list < MC->Cnt; list++)
  62                 :             :     {
  63   [ -  +  #  # ]:           7 :         if(id != MC->List[list])
  64                 :             :         {
  65                 :             :             return TRUE;
  66                 :             :         }
  67                 :             :     }
  68                 :             : 
  69                 :             :     return FALSE;
  70                 :             : }

FN:52,70,check FNDA:0,check BRDA:56,0,0,1 BRDA:56,0,1,1 BRDA:56,0,2,- BRDA:56,0,3,- BRDA:61,0,0,1 BRDA:61,0,1,1 BRDA:61,0,2,- BRDA:61,0,3,- BRDA:63,0,0,0 BRDA:63,0,1,1 BRDA:63,0,2,- BRDA:63,0,3,- DA:52,0 DA:56,31 DA:61,16 DA:63,7

[henry2cox]

Yes - this looks a bit strange/not consistent. One would expect to see the function definition line also hit, an either line 65 or 69, if we got to line 61. It is possible that this is an lcov bug - but it is far more likely to be inconsistency in the data generated by gcc/gcov. (That is: a gcc instrumentation bug, or a gcov translation bug.)

If possible, try a newer GCC or LLVM and see if the issue disappears. (Note that - once you have that newer result, you can ask genhtml to generate a differential coverage report to compare the two - and see what is different.)

You can also try a newer lcov (say, by cloning the TOT or possibly downloading the 2.1-beta release version available above.) I suspect that that won't produce a different result, though.

If you have a testcase which exhibits the issue: please attach.

Thanks

Henry

[shaybra]

could the function have gotten inlined at compile time by any chance? Hence why it's internals got hit and not the function definition itself? Could you provide what your compiler flags are especially the optimization flag used?

[yangsee0]

could the function have gotten inlined at compile time by any chance? Hence why it's internals got hit and not the function definition itself? Could you provide what your compiler flags are especially the optimization flag used?

Hello. It is performed with the options below.

-- C Flags : -Wbad-function-cast -Wincompatible-pointer-types-discards-qualifiers -Wenum-enum-conversion -Wimplicit-float-conversion -Wimplicit-int-float-conversion -Wimplicit-int-conversion -Wshorten-64-to-32 -O2 -D'_FILENAME="$(subst .o,,$(@F))"' -march=cascadelake -Walloca -Wshift-overflow -Wstack-protector -Wformat -Wshadow -Wswitch-default -Wnull-dereference -Wredundant-decls -Wmissing-include-dirs -Wfloat-conversion -Wconversion -Wsign-conversion -Wall -Wextra -- CXX Flags : -Wincompatible-pointer-types-discards-qualifiers -Wenum-enum-conversion -Wimplicit-float-conversion -Wimplicit-int-float-conversion -Wimplicit-int-conversion -Wshorten-64-to-32 -O2 -D'_FILENAME="$(subst .o,,$(@F))"' -march=cascadelake -Walloca -Wshift-overflow -Wstack-protector -Wformat -Wshadow -Wswitch-default -Wnull-dereference -Wredundant-decls -Wmissing-include-dirs -Wfloat-conversion -Wconversion -Wsign-conversion -Wall -Wextra

[shaybra]

@yangsee0 try removing the O2 flag and see if that helps after a recompile and run. I don't know if the inlining of functions has been overlooked or not when accounting for function coverage in gcov but it's worth a shot to try and see. Or you could use the gcc attribute noinline which will force the function not to be inlined by the compiler. follow this link for more

[yangsee0]

Thank you for your advice. The optimization option has been blocked and resolved. We also confirmed that there is no problem with gcc 9.4.0.

[shaybra]

Thank you for your advice. The optimization option has been blocked and resolved. We also confirmed that there is no problem with gcc 9.4.0.

happy to help!