Thanks for the help.
Can you elaborate on your comment about -O0 producing not-useful results?
I am only using it in the context of compiling for coverage and was trying
to avoid any gotchas (I have seen gcc produce incorrect code when using
the coverage options with optimization).
I'm confused also as to why the extra options you used were necessary.
>From the man page, there are two paragraphs about -fno-default-inline:
-fno-default-inline
Do not assume inline for functions defined inside a class scope.
Note that these functions will have linkage like inline functions;
they just won't be inlined by default.
-fno-default-inline
Do not make member functions inline by default merely because they
are defined inside the class scope (C++ only). Otherwise, when you
specify -O, member functions defined inside class scope are
compiled inline by default; i.e., you don't need to add inline in
front of the member function name.
I'm not sure which one reflects reality. The second suggests that the
option only makes a difference when using -O (i.e., member functions
defined inside class scope shouldn't be treated as inline with -O0).
And, for -fkeep-inline-functions:
-fkeep-inline-functions
In C, emit "static" functions that are declared "inline" into the
object file, even if the function has been inlined into all of its
callers. This switch does not affect functions using the "extern
inline" extension in GNU C. In C++, emit any and all inline
functions into the object file.
If, at -O0, the member functions aren't considered inline functions, then
this option should have no effect, but perhaps the 2nd paragraph about
-fno-default-inline is incorrect and the default behavior for these member
functions is to inline them even at -O0. If so, I question whether that
makes sense. Since it also affects .gcno output, perhaps -fprofile-arcs
should imply these other two options.
Finally, while I haven't been able to come up with a nice test case to
post here, another anomaly I discovered is that the the .gcno file will
list a line as instrumented but doesn't list the corresponding function,
making tools like gcov or lcov think the line is part of a different
function. Using the new options seems to make this go away, so I guess
it's not that important, but I thought I'd mention it to see if anyone
else ever saw something like that or thinks it should be fixed.
Perhaps gcov usage is very rare out there.
Michael
--- John Love-Jensen <eljay@xxxxxxxxx> wrote:
> Hi Michael,
>
> Keep in mind that profiling -O0 produces not-useful results for
> performance
> profiling. (It may produce useful results for other purposes. Such as
> code
> exercise coverage.)
>
> I tweaked your compile flags:
>
> # g++ -fprofile-arcs \
> -ftest-coverage \
> -fno-default-inline \
> -fkeep-inline-functions \
> -O0 -o rect main.cpp
>
> # ./rect
>
> # gcov -l -f main.gcda | c++filt -n
>
> Hey, that's useful info! I've never used gcov before.
>
> HTH,
> --Eljay
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
