> On 7/31/20 10:47 AM, Jan Hubicka wrote:
> > I think this needs to be restricted to targets that have dl library
>
> Hm, I can't find a dg-require that is used for similar test-cases.
OK, lets get it in and see if it breaks :)
Honza
>
> Martin
On 7/31/20 10:47 AM, Jan Hubicka wrote:
I think this needs to be restricted to targets that have dl library
Hm, I can't find a dg-require that is used for similar test-cases.
Martin
> On 6/3/20 8:28 AM, Martin Liška wrote:
> > On 6/2/20 3:19 PM, Martin Liška wrote:
> > > I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
> > > Please take a look at the attached patch. I also added a test-case that
> > > stresses that. I've just finished LTO PGO bootstrap
On 6/3/20 8:28 AM, Martin Liška wrote:
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I've just finished LTO PGO bootstrap of the GCC.
Ready fo
PING^2
On 6/17/20 8:38 AM, Martin Liška wrote:
PING^1
On 6/3/20 8:28 AM, Martin Liška wrote:
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I
PING^1
On 6/3/20 8:28 AM, Martin Liška wrote:
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I've just finished LTO PGO bootstrap of the GCC.
On 6/8/20 1:07 PM, Martin Liška wrote:
Can you please test the following patch candidate:
I've just pushed 862b9b225fb which should fix that.
Can you please test the current master?
Thanks,
Martin
On 6/4/20 1:44 AM, Gerald Pfeifer wrote:
On Wed, 3 Jun 2020, Martin Liška wrote:
Sorry for the breakage. Can you please paste full build output for the
problematic .o file?
I bet it's a C file compilation, where we should use:
__sync_val_compare_and_swap (counter, 0, (intptr_t)node);
Can you
On Wed, 3 Jun 2020, Martin Liška wrote:
> Sorry for the breakage. Can you please paste full build output for the
> problematic .o file?
>
> I bet it's a C file compilation, where we should use:
>
> __sync_val_compare_and_swap (counter, 0, (intptr_t)node);
>
> Can you please test it?
c++ -std=c
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I've just finished LTO PGO bootstrap of the GCC.
Ready for master?
There's V2 of the patch:
-
On 6/3/20 3:07 AM, Gerald Pfeifer wrote:
On Tue, 2 Jun 2020, Martin Liška wrote:
Ready for master?
Before that, my nightly tester on i386-unknown-freebsd11 just ran into
the following:
/scratch/tmp/gerald/GCC-HEAD/gcc/../libgcc/libgcov.h:396:51: error:
cannot initialize a parameter of t
On Tue, 2 Jun 2020, Martin Liška wrote:
> Ready for master?
Before that, my nightly tester on i386-unknown-freebsd11 just ran into
the following:
/scratch/tmp/gerald/GCC-HEAD/gcc/../libgcc/libgcov.h:396:51: error:
cannot initialize a parameter of type 'gcov_type' (aka 'long long')
with a
On 6/2/20 10:27 AM, Jan Hubicka wrote:
The patch looks good (and is OK for mainline). I am bit concerned about
two things.
Hello.
Thank you for the review!
1) I think we should add support to pre-allocate memory pool so we hide
the problem with instrumenting malloc (I think with big eno
>
> 2020-04-03 Martin Liska
>
> * coverage.c (get_coverage_counts): Skip sanity check for TOP N counters
> as they have variable number of counters.
> * gcov-dump.c (main): Add new option -r.
> (print_usage): Likewise.
> (tag_counters): All new raw format.
>
PING^2
On 5/15/20 11:57 AM, Martin Liška wrote:
We're in stage1: PING^
On 5/15/20 1:03 PM, Jan Hubicka wrote:
I wonder, did we somehow solved the issue with Firefox breaking due to
malloc instrumentation?
Yes, you proposed a patch:
https://hg.mozilla.org/try/rev/e1358ef2d82c035b12f8995712580c77bd9f8d43
Which I believe was sent to Firefox?
Martin
> We're in stage1: PING^1
I wonder, did we somehow solved the issue with Firefox breaking due to
malloc instrumentation?
Honza
>
> On 4/6/20 10:03 AM, Martin Liška wrote:
> > Hi.
> >
> > We've started discussion the patch with Honza when we started working on
> > reproducibility of -fprofile-ge
We're in stage1: PING^1
On 4/6/20 10:03 AM, Martin Liška wrote:
Hi.
We've started discussion the patch with Honza when we started working on
reproducibility of -fprofile-generate/use. The patch replaces pre-allocated
TOP N counters with a dynamical linked list allocation that happens during
pro
Hi.
We've started discussion the patch with Honza when we started working on
reproducibility of -fprofile-generate/use. The patch replaces pre-allocated
TOP N counters with a dynamical linked list allocation that happens during
profiling. The similar approach is used by Clang and it provides thes
19 matches
Mail list logo
