* PR 23296: Strange -O3 -finstrument-functions behaviour
@ 2009-06-29 14:23 Richard Sandiford
2009-06-29 21:48 ` Ian Lance Taylor
0 siblings, 1 reply; 2+ messages in thread
From: Richard Sandiford @ 2009-06-29 14:23 UTC (permalink / raw)
To: gcc; +Cc: bart.vanassche
A colleague recently came across the interaction between
-finstrument-functions and inline functions mentioned here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23296
As the bug submitter says, the problem is that for something like:
#include <stdio.h>
void g (void) { printf("Here\n"); }
int main (void) { g (); return 0; }
compiled with "-O3 -finstrument-functions", you get two successive calls
to __cyg_profile_func_enter _with the same arguments_. That is, both
calls say that they are entering main():
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
Is this really the intended behaviour? Andrew closed the bug as invalid,
saying that this is what we expect, but the docs seem to suggest that we
ought to do something like:
...
__cyg_profile_func_enter (&main, ...);
...
__cyg_profile_func_enter (&g, ...);
...
__cyg_profile_func_exit (&g, ...);
...
__cyg_profile_func_exit (&main, ...);
...
instead. [I'm going off:
This instrumentation is also done for functions expanded inline in other
functions. The profiling calls will indicate where, conceptually, the
inline function is entered and exited. This means that addressable
versions of such functions must be available. If all your uses of a
function are expanded inline, this may mean an additional expansion of
code size. If you use @samp{extern inline} in your C code, an
addressable version of such functions must be provided. (This is
normally the case anyways, but if you get lucky and the optimizer always
expands the functions inline, you might have gotten away without
providing static copies.)
Although it doesn't explicitly say _why_ we need addressable versions,
the context suggests to me that we're supposed to be passing them
as the "this_fn" argument to the hooks.]
Richard
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: PR 23296: Strange -O3 -finstrument-functions behaviour
2009-06-29 14:23 PR 23296: Strange -O3 -finstrument-functions behaviour Richard Sandiford
@ 2009-06-29 21:48 ` Ian Lance Taylor
0 siblings, 0 replies; 2+ messages in thread
From: Ian Lance Taylor @ 2009-06-29 21:48 UTC (permalink / raw)
To: gcc; +Cc: bart.vanassche, richards
Richard Sandiford <richards@transitive.com> writes:
> Is this really the intended behaviour? Andrew closed the bug as invalid,
> saying that this is what we expect, but the docs seem to suggest that we
> ought to do something like:
>
> ...
> __cyg_profile_func_enter (&main, ...);
> ...
> __cyg_profile_func_enter (&g, ...);
> ...
> __cyg_profile_func_exit (&g, ...);
> ...
> __cyg_profile_func_exit (&main, ...);
> ...
I agree. The docs seem reasonably clear.
Ian
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-06-29 21:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-29 14:23 PR 23296: Strange -O3 -finstrument-functions behaviour Richard Sandiford
2009-06-29 21:48 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).