On Sun, Aug 5, 2012 at 11:44 AM, Dimitrios Apostolou wrote:
>
> No problem, if anyone else doesn't object I'll change those (in a second
> patch, right?).
Can you please resend the patch you propose to check into mainline? Thanks.
Ian
On Sat, 4 Aug 2012, Ian Lance Taylor wrote:
On Fri, 3 Aug 2012, Ian Lance Taylor wrote:
I'm not sure where you are looking. I only see one call to
_obstack_begin in the gcc directory, and it could easily be replaced
with a call to obstack_specify_allocation instead.
In libcpp/ mostly, but o
On Sat, Aug 4, 2012 at 9:40 AM, Dimitrios Apostolou wrote:
> On Fri, 3 Aug 2012, Ian Lance Taylor wrote:
>
>>> 2012-08-04 Dimitrios Apostolou
>>>
>>> * libiberty.h
>>> (XOBDELETE,XOBGROW,XOBGROWVEC,XOBSHRINK,XOBSHRINKVEC): New
>>> type-safe macros for obstack allocation.
>
On Fri, 3 Aug 2012, Ian Lance Taylor wrote:
2012-08-04 Dimitrios Apostolou
* libiberty.h
(XOBDELETE,XOBGROW,XOBGROWVEC,XOBSHRINK,XOBSHRINKVEC): New
type-safe macros for obstack allocation.
(XOBFINISH): Renamed argument to PT since it is a pointer to T.
+/* Ty
> 2012-08-04 Dimitrios Apostolou
>
> * libiberty.h
> (XOBDELETE,XOBGROW,XOBGROWVEC,XOBSHRINK,XOBSHRINKVEC): New
> type-safe macros for obstack allocation.
> (XOBFINISH): Renamed argument to PT since it is a pointer to T.
> +/* Type-safe obstack allocator. You must
Hi Dodji, I appreciate your review but I'm replying for now only for the
libiberty.h part (attached updated patch), which I've needed elsewhere and
seems the easiest to quickly apply.
On Wed, 18 Jul 2012, Dodji Seketeli wrote:
=== modified file 'include/libiberty.h'
--- include/libiberty.h 2
Hello Dimitrios,
> With the attached patches I introduce four new obstacks in struct
> cpp_reader to substitute malloc's/realloc's when expanding
> macros. Numbers have been posted in the PR, but to summarize:
>
> before: 0.785 s or 2201 M instr
> after: 0.760 s or 2108 M instr
>
> Memory ove
With the attached patches I introduce four new obstacks in struct
cpp_reader to substitute malloc's/realloc's when expanding macros. Numbers
have been posted in the PR, but to summarize:
before: 0.785 s or 2201 M instr
after: 0.760 s or 2108 M instr
Memory overhead is some tens kilobytes wo
