My bad.
Thanks for the fix!
-Rong
On Thu, Jan 9, 2014 at 11:47 AM, H.J. Lu wrote:
> On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu wrote:
>> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
@@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
#endif
/* crc32 for this program. *
On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu wrote:
> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>>> @@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
>>> #endif
>>> /* crc32 for this program. */
>>> static gcov_unsigned_t crc32;
>>> +/* Use this summary checksum rather the computed
>
> I don't understand why static variables can cause any safety issue in
> multi-thread programs.
> For any process, gcov_dump will be called only once and there will be
> one instance of globals.
(v)fork, failing exec and other cases can lead to gcov_flush being called
several times and that c
On Wed, Jan 8, 2014 at 2:20 PM, Rong Xu wrote:
> On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li wrote:
#ifdef L_gcov_merge_ior
/* The profile merging function that just adds the counters. It is given
- an array COUNTERS of N_COUNTERS old counters and it reads the same
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> @@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
>> #endif
>> /* crc32 for this program. */
>> static gcov_unsigned_t crc32;
>> +/* Use this summary checksum rather the computed one if the value is
>> + *non-zero. */
>> +static
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li wrote:
>>>
>>> #ifdef L_gcov_merge_ior
>>> /* The profile merging function that just adds the counters. It is given
>>> - an array COUNTERS of N_COUNTERS old counters and it reads the same
>>> number
>>> - of counters from the gcov file.
Here is the patch that addresses Honza's concern about bss increment.
It just makes this_prg a local variable.
Some comments are inlined.
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>
> Do you know how the size of libgcov changed with your patch?
> Quick check of current mainline on
>>
>> #ifdef L_gcov_merge_ior
>> /* The profile merging function that just adds the counters. It is given
>> - an array COUNTERS of N_COUNTERS old counters and it reads the same number
>> - of counters from the gcov file. */
>> + an array COUNTERS of N_COUNTERS old counters.
>> + When S
On Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson wrote:
> On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li wrote:
>> Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
>> low level primitives for basic gcov format and probably should be kept
>> in gcov-io.c.
>>
>> gcov_rewrite i
On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li wrote:
> Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
> low level primitives for basic gcov format and probably should be kept
> in gcov-io.c.
>
> gcov_rewrite is petty much libgcov runtime implementation details so I
> thin
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in gcov-io.c.
gcov_rewrite is petty much libgcov runtime implementation details so I
think it should be moved out. gcov_write_summary is not related to
gcov lo
> I think so -- they are private to libgcov. Honza, what do you think?
Hmm, the purpose of gcov-io was to be low level IO library for the basic
gcov file format. I am not sure if gcov_write_tag_length should really resist
in other file than gcov_write_tag.
I see a desire to isolate actual stdio
I think so -- they are private to libgcov. Honza, what do you think?
thanks,
David
On Mon, Dec 16, 2013 at 1:17 PM, Teresa Johnson wrote:
> On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li
> wrote:
>> gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
>> Should it be move
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li wrote:
> gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
> Should it be moved from common file gcov-io.c to libgcov.c?
Possibly. I just looked through gcov-io.c and there are several
additional functions that are only defined
gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
Should it be moved from common file gcov-io.c to libgcov.c?
David
On Thu, Dec 12, 2013 at 12:11 PM, Teresa Johnson wrote:
> On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson wrote:
>> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka
On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson wrote:
> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>>> Hi, all
>>>
>>> This is the new patch for gcov-tool (previously profile-tool).
>>>
>>> Honza: can you comment on the new merge interface? David posted some
>>> comments in an earlier e
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> Hi, all
>>
>> This is the new patch for gcov-tool (previously profile-tool).
>>
>> Honza: can you comment on the new merge interface? David posted some
>> comments in an earlier email and we want to know what's your opinion.
>>
>> Test patch ha
On Tue, Dec 10, 2013 at 11:01 AM, Xinliang David Li wrote:
> I agree with the staged checkin plan proposed. Teresa, can you help
> with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
> trip..)
Sure, I will work on that part and send a patch once it is tested.
Teresa
>
> thanks,
I agree with the staged checkin plan proposed. Teresa, can you help
with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
trip..)
thanks,
David
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> Hi, all
>>
>> This is the new patch for gcov-tool (previously profile-tool).
>>
>>
> Hi, all
>
> This is the new patch for gcov-tool (previously profile-tool).
>
> Honza: can you comment on the new merge interface? David posted some
> comments in an earlier email and we want to know what's your opinion.
>
> Test patch has been tested with boostrap, regresssion,
> profiledboots
Ping.
On Mon, Nov 18, 2013 at 12:31 PM, Xinliang David Li wrote:
> gcov-dump tool does raw dump of profile data. In the long run, we
> should have only one gcov profile manipulation tool, so it might be
> better to incorporate gcov-dump into gcov-tool and get rid of
> 'gcov-dump'.
>
> David
>
> O
gcov-dump tool does raw dump of profile data. In the long run, we
should have only one gcov profile manipulation tool, so it might be
better to incorporate gcov-dump into gcov-tool and get rid of
'gcov-dump'.
David
On Mon, Nov 18, 2013 at 12:24 PM, Rong Xu wrote:
> Hi, all
>
> This is the new pa
The patch was checked in as r204730.
Tested with
configure with --enable-languages=all,obj-c++
(ada is currently broken, so I was not be able test)
bootstrap and profiledbootstrap
regression for -m32 and -m64.
spec2006
The only semantic change is __gcov_flush() used to be under L_gcov.
I put the
On Mon, Nov 11, 2013 at 7:17 AM, Jan Hubicka wrote:
>> Here is the patch that includes profile-tool.
>> Profile-tool now has two functions: merge and rewrite. I'll add diff later.
>>
>> Compiler is tested with spec2006 and profiledbootstrap.
>> profile-tool is tested with spec2006 profiles.
>
> Hi
On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka wrote:
>> 2013-11-04 Rong Xu
>>
>> * libgcc/libgcov.c: Delete as part of re-factoring.
>> * libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
>> libgcov.c
>> (__gcov_pow2_profiler): Ditto.
>> (__gcov_one_v
> Here is the patch that includes profile-tool.
> Profile-tool now has two functions: merge and rewrite. I'll add diff later.
>
> Compiler is tested with spec2006 and profiledbootstrap.
> profile-tool is tested with spec2006 profiles.
Hi,
it would be nice if you could elaborate bit more on the to
> 2013-11-04 Rong Xu
>
> * libgcc/libgcov.c: Delete as part of re-factoring.
> * libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
> libgcov.c
> (__gcov_pow2_profiler): Ditto.
> (__gcov_one_value_profiler_body): Ditto.
> (__gcov_one_value_profi
On Fri, 8 Nov 2013, Rong Xu wrote:
> A question about inhibit_libc.
> When inhibit_libc is defined, we provide dummy functions for all the
> __gcov_* methods.
> Is it purposely to minimize the footprint?
inhibit_libc is for use in bootstrap builds when libc headers aren't
available - for buildin
On Fri, Nov 8, 2013 at 11:30 AM, Xinliang David Li wrote:
> On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu wrote:
>> On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li
>> wrote:
>>> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
wrote:
On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu wrote:
> On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li wrote:
>> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
>>> wrote:
in libgcov-driver.c
> /* Flag when the profile has alre
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li wrote:
> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
>> wrote:
>>> in libgcov-driver.c
>>>
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gc
On Fri, Nov 8, 2013 at 10:56 AM, Rong Xu wrote:
> A question about inhibit_libc.
> When inhibit_libc is defined, we provide dummy functions for all the
> __gcov_* methods.
> Is it purposely to minimize the footprint?
> I'm thinking to allow some codes that are independent of libc (and its
> header
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li wrote:
>> in libgcov-driver.c
>>
>>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>>> static int gcov_dump_complete;
>>
>>> inline void
>>> set_gcov_dump_complete (void)
A question about inhibit_libc.
When inhibit_libc is defined, we provide dummy functions for all the
__gcov_* methods.
Is it purposely to minimize the footprint?
I'm thinking to allow some codes that are independent of libc (and its
headers) under this. Is it OK?
-Rong
On Fri, Nov 8, 2013 at 10:48
> 1) I don't think you need in_mem flag. For in memory merge, the source !=
> NULL.
discard this comment.
David
>
>
>
>
>
>
> On Thu, Nov 7, 2013 at 3:34 PM, Rong Xu wrote:
>> On Thu, Nov 7, 2013 at 9:40 AM, Joseph S. Myers
>> wrote:
>>> On Thu, 7 Nov 2013, Rong Xu wrote:
>>>
Thanks Jose
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li wrote:
> in libgcov-driver.c
>
>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>> static int gcov_dump_complete;
>
>> inline void
>> set_gcov_dump_complete (void)
>>{
> > gcov_dump_complete = 1;
>>}
>
>>inline void
>>r
in libgcov-driver.c
> /* Flag when the profile has already been dumped via __gcov_dump(). */
> static int gcov_dump_complete;
> inline void
> set_gcov_dump_complete (void)
>{
> gcov_dump_complete = 1;
>}
>inline void
>reset_gcov_dump_complete (void)
>{
> gcov_dump_complete = 0;
>}
These sh
On Thu, 7 Nov 2013, Rong Xu wrote:
> Thanks Joseph for these detailed comments/suggestions.
> The fixed patch is attached to this email.
> The only thing left out is the Texinfo manual. Do you mean this tool
> should have its it's own texi file in gcc/doc?
Its own texi file, probably included as
On Wed, 6 Nov 2013, Rong Xu wrote:
> In current implementation, if you use 'profile-tool help', it will
> print out the usage and exit.
Please make sure you follow the GNU Coding Standards. Any installed tool
needs to support --help, with output following the GNU Coding Standards,
to standard
I have not looked this in detail, but it looks like the copy right
header of the new file is wrong (including the year).
You should 1) document the command line syntax somewhere, possibly in
comment? 2) add a help command for the tool to dump out help message.
David
On Wed, Nov 6, 2013 at 1:25
Those functions are not referencing each other, but they get used in
different logical groups, so at least control granularity can be
improved. For instance,
1) all gcov user interfaces such as gcov_dump, gcov_flush, gcov_reset
are either not used at all, or all of them are used -- there is no
need
On Tue, Nov 05, 2013 at 10:18:50AM +0100, Jan Hubicka wrote:
> > I wonder if it makes sense to get rid of the conditional compile such as
> >
> > #ifdef L_gcov_x
> > ..
> >
> > #endif
> >
> > This has the advantage of producing slightly smaller instrumented
> > binary, but this benefit can a
> I wonder if it makes sense to get rid of the conditional compile such as
>
> #ifdef L_gcov_x
> ..
>
> #endif
>
> This has the advantage of producing slightly smaller instrumented
> binary, but this benefit can also be achieved via -ffunction-sections
> and let linker to garbage collect unu
I wonder if it makes sense to get rid of the conditional compile such as
#ifdef L_gcov_x
..
#endif
This has the advantage of producing slightly smaller instrumented
binary, but this benefit can also be achieved via -ffunction-sections
and let linker to garbage collect unused functions.
(pro
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote:
> Honza, Thanks for the comments!
> Attached is the patch.
> Passed spec2006 fdo build and profiledbootstrap in gcc.
> I'm doing some other tests.
>
> -Rong
>
> On Mon, Nov 4, 2013 at 1:55 AM, Jan Hubicka wrote:
>>> Thanks! Can you attach the patch f
BTW, this part of patch only does the re-factoring work.
I haven't finished the porting of profile-tool part of patch to the
trunk. They should be in a separate patch anyway.
-Rong
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote:
> Honza, Thanks for the comments!
> Attached is the patch.
> Passed
> Thanks! Can you attach the patch file for the proposed change?
>
> David
>
> On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu wrote:
> > libgcov.c is the main file to generate libgcov.a. This single source
> > generates
> > 21 object files and then archives to a library. These objects are of
> > very
Thanks! Can you attach the patch file for the proposed change?
David
On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu wrote:
> libgcov.c is the main file to generate libgcov.a. This single source generates
> 21 object files and then archives to a library. These objects are of
> very different purposes bu
libgcov.c is the main file to generate libgcov.a. This single source generates
21 object files and then archives to a library. These objects are of
very different purposes but they are in the same file guarded by various macros.
The source file becomes quite large and its readability becomes very
l
49 matches
Mail list logo
