> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not
PING^3
On 2/9/21 9:37 AM, Martin Liška wrote:
PING^2
@Honza: ?
On 1/29/21 2:33 PM, Martin Liška wrote:
PING^1
On 1/25/21 1:51 PM, Martin Liška wrote:
On 1/22/21 3:33 PM, Jan Hubicka wrote:
It is definitly doable (gcov machinery is quite flexible WRT having more
types of counters).
Yes,
On Tue, Feb 09, 2021 at 09:37:12AM +0100, Martin Liška wrote:
> PING^2
>
> @Honza: ?
Just concerning Windows (though I don't have access to that OS and can't
verify), e.g.
https://github.com/m-labs/uclibc-lm32/blob/master/utils/mmap-windows.c
contains public domain code to emulate mmap on top of
PING^2
@Honza: ?
On 1/29/21 2:33 PM, Martin Liška wrote:
PING^1
On 1/25/21 1:51 PM, Martin Liška wrote:
On 1/22/21 3:33 PM, Jan Hubicka wrote:
It is definitly doable (gcov machinery is quite flexible WRT having more
types of counters).
Yes, that would introduce back the dropped TOPN
PING^1
On 1/25/21 1:51 PM, Martin Liška wrote:
On 1/22/21 3:33 PM, Jan Hubicka wrote:
It is definitly doable (gcov machinery is quite flexible WRT having more
types of counters).
Yes, that would introduce back the dropped TOPN counters which I intentionally
dropped.
We could bring back
On 1/22/21 3:33 PM, Jan Hubicka wrote:
It is definitly doable (gcov machinery is quite flexible WRT having more
types of counters).
Yes, that would introduce back the dropped TOPN counters which I intentionally
dropped.
We could bring back topn counters or the easier dominating vlaue ones
> > It is definitly doable (gcov machinery is quite flexible WRT having more
> > types of counters).
>
> Yes, that would introduce back the dropped TOPN counters which I intentionally
> dropped.
We could bring back topn counters or the easier dominating vlaue ones
and add command line option.
On 1/22/21 3:10 PM, Jan Hubicka wrote:
On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
On 1/22/21 2:38 PM, Jan Hubicka wrote:
This looks like reasonable solution for Linux (i was thinking of it too)
but I wonder what about setups w/o mmap support, like mingw32?
The code still uses
> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
> >
> > On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > > This looks like reasonable solution for Linux (i was thinking of it too)
> > > but I wonder what about setups w/o mmap support, like mingw32?
> >
> > The code still uses malloc approach
On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
>
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I think we need some fallback there. I was wondering if
On 1/22/21 2:38 PM, Jan Hubicka wrote:
This looks like reasonable solution for Linux (i was thinking of it too)
but I wonder what about setups w/o mmap support, like mingw32?
The code still uses malloc approach then.
I think we need some fallback there. I was wondering if simply
disabling
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not
13 matches
Mail list logo
