public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).