> On 10/27/20 11:29 AM, Jan Hubicka wrote:
> > Looks reasonable, but I do not like very much the non-configurable
> > preallocation since libgcov was meant to be useful for embedded targets
> > and not consume too much.
>
> Sure, we can handle that later when it's really an issue.
>
> > I guess w
On 10/27/20 11:29 AM, Jan Hubicka wrote:
Looks reasonable, but I do not like very much the non-configurable
preallocation since libgcov was meant to be useful for embedded targets
and not consume too much.
Sure, we can handle that later when it's really an issue.
I guess we could handle that
> > Hello.
> >
> > As noticed in the PR, it's quite tricky to not run malloc (or calloc)
> > in context of libgcov. I'm suggesting a new approach where we'll first
> > use the pre-allocated static buffer in hope that malloc function is
> > initialized
> > and so every call to calloc can happen. T
@Honza: PING
Thanks
On 10/20/20 11:10 AM, Martin Liška wrote:
Hello.
As noticed in the PR, it's quite tricky to not run malloc (or calloc)
in context of libgcov. I'm suggesting a new approach where we'll first
use the pre-allocated static buffer in hope that malloc function is initialized
and
Hello.
As noticed in the PR, it's quite tricky to not run malloc (or calloc)
in context of libgcov. I'm suggesting a new approach where we'll first
use the pre-allocated static buffer in hope that malloc function is initialized
and so every call to calloc can happen. That's why I increased number
