Use vec::reserve before vec_safe_grow_cleared is called

Message ID 8bf8b90a-6d10-90e3-62aa-633f7bbf71be@suse.cz
State New
Headers show
Series
  • Use vec::reserve before vec_safe_grow_cleared is called
Related show

Commit Message

Martin Liška July 25, 2020, 12:22 p.m.
Hello.

When inserting into fast_call_summary (or fast_function_summary), we grow
a vector to a _exact_ size based on cgraph_max_summary_id or edges_max_summary_id.
Problem is that it causes very many reallocation and we should rather use ::reserve
function that selects a reasonable size of a new vector.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Fixes chromium WPA build time:
https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/f766f6546739e739a273639dde90ac6179aa3077/chromium-gcc10-fixed-summary-crash.svg

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

	* symbol-summary.h: Call vec_safe_reserve before grow is called
	in order to grow to a reasonable size.
	* vec.h (vec_safe_reserve): Add missing function for vl_ptr
	type.
---
  gcc/symbol-summary.h | 13 ++++++++++---
  gcc/vec.h            | 11 +++++++++++
  2 files changed, 21 insertions(+), 3 deletions(-)

-- 
2.27.0

Comments

Bill Schmidt via Gcc-patches July 27, 2020, 7:11 a.m. | #1
On Sat, Jul 25, 2020 at 2:23 PM Martin Liška <mliska@suse.cz> wrote:
>

> Hello.

>

> When inserting into fast_call_summary (or fast_function_summary), we grow

> a vector to a _exact_ size based on cgraph_max_summary_id or edges_max_summary_id.

> Problem is that it causes very many reallocation and we should rather use ::reserve

> function that selects a reasonable size of a new vector.

>

> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

> Fixes chromium WPA build time:

> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/f766f6546739e739a273639dde90ac6179aa3077/chromium-gcc10-fixed-summary-crash.svg

>

> Ready to be installed?


OK.  I guess the previous code tried to use less memory.

Thanks,
Richard.

> Thanks,

> Martin

>

> gcc/ChangeLog:

>

>         * symbol-summary.h: Call vec_safe_reserve before grow is called

>         in order to grow to a reasonable size.

>         * vec.h (vec_safe_reserve): Add missing function for vl_ptr

>         type.

> ---

>   gcc/symbol-summary.h | 13 ++++++++++---

>   gcc/vec.h            | 11 +++++++++++

>   2 files changed, 21 insertions(+), 3 deletions(-)

>

> diff --git a/gcc/symbol-summary.h b/gcc/symbol-summary.h

> index a38eb1db778..fa1df5c8015 100644

> --- a/gcc/symbol-summary.h

> +++ b/gcc/symbol-summary.h

> @@ -354,8 +354,11 @@ public:

>         id = this->m_symtab->assign_summary_id (node);

>

>       if ((unsigned int)id >= m_vector->length ())

> -      vec_safe_grow_cleared (m_vector,

> -                            this->m_symtab->cgraph_max_summary_id);

> +      {

> +       int newlen = this->m_symtab->cgraph_max_summary_id;

> +       vec_safe_reserve (m_vector, newlen - m_vector->length ());

> +       m_vector->quick_grow_cleared (newlen);

> +      }

>

>       if ((*m_vector)[id] == NULL)

>         (*m_vector)[id] = this->allocate_new ();

> @@ -812,7 +815,11 @@ public:

>         id = this->m_symtab->assign_summary_id (edge);

>

>       if ((unsigned)id >= m_vector->length ())

> -      vec_safe_grow_cleared (m_vector, this->m_symtab->edges_max_summary_id);

> +      {

> +       int newlen = this->m_symtab->edges_max_summary_id;

> +       m_vector->reserve (newlen - m_vector->length ());

> +       m_vector->quick_grow_cleared (newlen);

> +      }

>

>       if ((*m_vector)[id] == NULL)

>         (*m_vector)[id] = this->allocate_new ();

> diff --git a/gcc/vec.h b/gcc/vec.h

> index bd7c7351dcd..3ad99b83690 100644

> --- a/gcc/vec.h

> +++ b/gcc/vec.h

> @@ -753,6 +753,17 @@ vec_safe_grow_cleared (vec<T, va_heap, vl_ptr> *&v,

>     v->safe_grow_cleared (len PASS_MEM_STAT);

>   }

>

> +/* If V does not have space for NELEMS elements, call

> +   V->reserve(NELEMS, EXACT).  */

> +

> +template<typename T>

> +inline bool

> +vec_safe_reserve (vec<T, va_heap, vl_ptr> *&v, unsigned nelems, bool exact = false

> +                 CXX_MEM_STAT_INFO)

> +{

> +  return v->reserve (nelems, exact);

> +}

> +

>

>   /* If V is NULL return false, otherwise return V->iterate(IX, PTR).  */

>   template<typename T, typename A>

> --

> 2.27.0

>
Martin Liška July 27, 2020, 7:14 a.m. | #2
On 7/27/20 9:11 AM, Richard Biener wrote:
> OK.  I guess the previous code tried to use less memory.


It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.

I'm going to backport the patch older releases as well.

Martin
Jan Hubicka July 27, 2020, 9:51 a.m. | #3
> On 7/27/20 9:11 AM, Richard Biener wrote:

> > OK.  I guess the previous code tried to use less memory.

> 

> It did. But I didn't realize that such exact growth would lead

> to a massive reallocation for huge apps like chromium.

> 

> I'm going to backport the patch older releases as well.


Thank you!  Did it solved the the Chromium problem?  I guess I can try
to do some profiling since this problem did not show on Firefox (that i
find odd given that Firefox is just about half of the size).
Perhaps glibc has some stupid limit in realloc that makes it to behave
in a silly way for very large arrays?

Honza
> 

> Martin
Martin Liška July 27, 2020, 10:29 a.m. | #4
On 7/27/20 11:51 AM, Jan Hubicka wrote:
>> On 7/27/20 9:11 AM, Richard Biener wrote:

>>> OK.  I guess the previous code tried to use less memory.

>>

>> It did. But I didn't realize that such exact growth would lead

>> to a massive reallocation for huge apps like chromium.

>>

>> I'm going to backport the patch older releases as well.

> 

> Thank you!  Did it solved the the Chromium problem?


Yes, I verified that.

> I guess I can try

> to do some profiling since this problem did not show on Firefox (that i

> find odd given that Firefox is just about half of the size).


Yep, I'm also surprised about it.

> Perhaps glibc has some stupid limit in realloc that makes it to behave

> in a silly way for very large arrays?


Dunno :P

Martin

> 

> Honza

>>

>> Martin
Jan Hubicka July 27, 2020, 10:48 a.m. | #5
> Yes, I verified that.

> 

> > I guess I can try

> > to do some profiling since this problem did not show on Firefox (that i

> > find odd given that Firefox is just about half of the size).

> 

> Yep, I'm also surprised about it.

> 

> > Perhaps glibc has some stupid limit in realloc that makes it to behave

> > in a silly way for very large arrays?

> 

> Dunno :P

Seems like glibc issue. On my debian testing box:

hubicka@lomikamen-jh:~$ cat t.c
#include <stdlib.h>
main(int argc, char **argv)
{
  char *a = malloc (1);
  int i,n=atoi(argv[1]);
  for (i=2;i<n;i++)
    a = realloc (a,i);
}

hubicka@lomikamen-jh:~$ time ./a.out 1000000000

real    0m10.057s
user    0m9.696s
sys     0m0.356s

And kunlun (which is a lot faster than my 2013 buldozer):


abuild@kunlun:~> time ./a.out 1000000000

real    0m59.808s
user    0m58.703s
sys     0m1.080s

GDB stops at:
(gdb) bt
#0  0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00005555555550bf in main ()
on debian while:
(gdb) bt
#0  0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6
#1  0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6
#2  0x00005555555550bf in main ()
on kunlun.

Perhaps someone enabled some cool security harnessing feature without
much of benchmarking :) (but even debian numbers seems like they can be
improved)

Honza
> 

> Martin

> 

> > 

> > Honza

> > > 

> > > Martin

>
Martin Liška July 27, 2020, 11 a.m. | #6
On 7/27/20 12:48 PM, Jan Hubicka wrote:
>> Yes, I verified that.

>>

>>> I guess I can try

>>> to do some profiling since this problem did not show on Firefox (that i

>>> find odd given that Firefox is just about half of the size).

>>

>> Yep, I'm also surprised about it.

>>

>>> Perhaps glibc has some stupid limit in realloc that makes it to behave

>>> in a silly way for very large arrays?

>>

>> Dunno :P

> Seems like glibc issue. On my debian testing box:

> 

> hubicka@lomikamen-jh:~$ cat t.c

> #include <stdlib.h>

> main(int argc, char **argv)

> {

>    char *a = malloc (1);

>    int i,n=atoi(argv[1]);

>    for (i=2;i<n;i++)

>      a = realloc (a,i);

> }

> 

> hubicka@lomikamen-jh:~$ time ./a.out 1000000000

> 

> real    0m10.057s

> user    0m9.696s

> sys     0m0.356s

> 

> And kunlun (which is a lot faster than my 2013 buldozer):

> 

> 

> abuild@kunlun:~> time ./a.out 1000000000

> 

> real    0m59.808s

> user    0m58.703s

> sys     0m1.080s


It runs for me in:

$ time ./a.out 1000000000

real	0m10.048s
user	0m9.742s
sys	0m0.305s

Note that there may be an interleaving load on the machine.
Perf says:

     55.40%  a.out    libc-2.26.so      [.] realloc
     36.01%  a.out    a.out             [.] realloc@plt
      4.98%  a.out    libc-2.26.so      [.] mremap_chunk
      3.60%  a.out    a.out             [.] main

while on my machine I see:

real	0m4.998s
user	0m4.947s
sys	0m0.050s

     54.49%  a.out    libc-2.31.so      [.] realloc
     37.63%  a.out    libc-2.31.so      [.] mremap_chunk
      3.72%  a.out    a.out             [.] realloc@plt

Martin

> 

> GDB stops at:

> (gdb) bt

> #0  0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6

> #1  0x00005555555550bf in main ()

> on debian while:

> (gdb) bt

> #0  0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6

> #1  0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6

> #2  0x00005555555550bf in main ()

> on kunlun.

> 

> Perhaps someone enabled some cool security harnessing feature without

> much of benchmarking :) (but even debian numbers seems like they can be

> improved)

> 

> Honza

>>

>> Martin

>>

>>>

>>> Honza

>>>>

>>>> Martin

>>
Jan Hubicka July 27, 2020, 11:03 a.m. | #7
> It runs for me in:

> 

> $ time ./a.out 1000000000

> 

> real	0m10.048s

> user	0m9.742s

> sys	0m0.305s


Did you do chroot to the chromium build?
> 

> Note that there may be an interleaving load on the machine.

> Perf says:

> 

>     55.40%  a.out    libc-2.26.so      [.] realloc

>     36.01%  a.out    a.out             [.] realloc@plt

>      4.98%  a.out    libc-2.26.so      [.] mremap_chunk

>      3.60%  a.out    a.out             [.] main


How one can do perfing on kunlun?
> 

> while on my machine I see:

> 

> real	0m4.998s

> user	0m4.947s

> sys	0m0.050s

> 

>     54.49%  a.out    libc-2.31.so      [.] realloc

>     37.63%  a.out    libc-2.31.so      [.] mremap_chunk

>      3.72%  a.out    a.out             [.] realloc@plt


Honza
> 

> Martin

> 

> > 

> > GDB stops at:

> > (gdb) bt

> > #0  0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6

> > #1  0x00005555555550bf in main ()

> > on debian while:

> > (gdb) bt

> > #0  0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6

> > #1  0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6

> > #2  0x00005555555550bf in main ()

> > on kunlun.

> > 

> > Perhaps someone enabled some cool security harnessing feature without

> > much of benchmarking :) (but even debian numbers seems like they can be

> > improved)

> > 

> > Honza

> > > 

> > > Martin

> > > 

> > > > 

> > > > Honza

> > > > > 

> > > > > Martin

> > > 

>
Bill Schmidt via Gcc-patches July 27, 2020, 11:07 a.m. | #8
On Mon, Jul 27, 2020 at 12:48 PM Jan Hubicka <hubicka@ucw.cz> wrote:
>

> > Yes, I verified that.

> >

> > > I guess I can try

> > > to do some profiling since this problem did not show on Firefox (that i

> > > find odd given that Firefox is just about half of the size).

> >

> > Yep, I'm also surprised about it.

> >

> > > Perhaps glibc has some stupid limit in realloc that makes it to behave

> > > in a silly way for very large arrays?

> >

> > Dunno :P

> Seems like glibc issue. On my debian testing box:


I'm sure in your actual testcase you run into fragmentation and
eventually fall out of cache which should make things worse by
an order of magnitude.

> hubicka@lomikamen-jh:~$ cat t.c

> #include <stdlib.h>

> main(int argc, char **argv)

> {

>   char *a = malloc (1);

>   int i,n=atoi(argv[1]);

>   for (i=2;i<n;i++)

>     a = realloc (a,i);

> }

>

> hubicka@lomikamen-jh:~$ time ./a.out 1000000000

>

> real    0m10.057s

> user    0m9.696s

> sys     0m0.356s

>

> And kunlun (which is a lot faster than my 2013 buldozer):

>

>

> abuild@kunlun:~> time ./a.out 1000000000

>

> real    0m59.808s

> user    0m58.703s

> sys     0m1.080s

>

> GDB stops at:

> (gdb) bt

> #0  0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6

> #1  0x00005555555550bf in main ()

> on debian while:

> (gdb) bt

> #0  0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6

> #1  0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6

> #2  0x00005555555550bf in main ()

> on kunlun.

>

> Perhaps someone enabled some cool security harnessing feature without

> much of benchmarking :) (but even debian numbers seems like they can be

> improved)

>

> Honza

> >

> > Martin

> >

> > >

> > > Honza

> > > >

> > > > Martin

> >
Jan Hubicka July 27, 2020, 11:11 a.m. | #9
> On 7/27/20 9:11 AM, Richard Biener wrote:

> > OK.  I guess the previous code tried to use less memory.

> 

> It did. But I didn't realize that such exact growth would lead

> to a massive reallocation for huge apps like chromium.


I would consider it an API issue - it is not really at all that obvious
when vec API does auto reserve and when it does not. 

Grepping for vec_safe_grow, rtl_create_basic_block, gimple_set_bb,
extend_h_i_d, stack_regs_mentioned, init_deps_data_vector
extend_insn_data, create_bb, move_block_to_fn logic has similar logic
but implemented by hand.  Perhaps we can switch it to the new API.  

combine_split_insns, combine_instructions, update_row_reg_save,
grow_label_align, update_uses, final_warning_record::grow_type_warnings,
sem_function::bb_dict_test, ::add_single_to_queue,
symtab_node::create_reference, mark_phi_for_rewrite, addr_for_mem_ref,
multiplier_allowed_in_address_p, get_address_cost_ainc,
make_ssa_name_fn, add_to_value, phi_translate_1,
optimize_range_tests_cmp_bitwise, set_strinfo,
ssa_name_values.safe_grow_cleared, vect_record_loop_mask has similarly
suspicious logic in it.  

Honza
> 

> I'm going to backport the patch older releases as well.

> 

> Martin
Martin Liška July 27, 2020, 11:22 a.m. | #10
On 7/27/20 1:03 PM, Jan Hubicka wrote:
> Did you do chroot to the chromium build?


Oh, you are right!

It really takes move than 60 seconds with:

     35.43%  a.out    libc-2.31.so      [.] mem2chunk_check
     26.54%  a.out    libc-2.31.so      [.] mem2mem_check
     21.50%  a.out    libc-2.31.so      [.] realloc_check
      8.38%  a.out    libc-2.31.so      [.] mremap_chunk
      5.03%  a.out    libc-2.31.so      [.] realloc
      1.87%  a.out    a.out             [.] main

So there's really a hardening enabled in openSUSE:Factory chroot.
@Andreas: Is it a known issue?

>> Note that there may be an interleaving load on the machine.

>> Perf says:

>>

>>      55.40%  a.out    libc-2.26.so      [.] realloc

>>      36.01%  a.out    a.out             [.] realloc@plt

>>       4.98%  a.out    libc-2.26.so      [.] mremap_chunk

>>       3.60%  a.out    a.out             [.] main

> How one can do perfing on kunlun?


You can install perf with:
osc build -x perf -x kernel-default

and then you can run it in a chroot env.

Martin
Martin Liška July 27, 2020, 11:24 a.m. | #11
On 7/27/20 1:11 PM, Jan Hubicka wrote:
>> On 7/27/20 9:11 AM, Richard Biener wrote:

>>> OK.  I guess the previous code tried to use less memory.

>>

>> It did. But I didn't realize that such exact growth would lead

>> to a massive reallocation for huge apps like chromium.

> 

> I would consider it an API issue - it is not really at all that obvious

> when vec API does auto reserve and when it does not.


Fully agree here, it's super-confusing.

> 

> Grepping for vec_safe_grow, rtl_create_basic_block, gimple_set_bb,

> extend_h_i_d, stack_regs_mentioned, init_deps_data_vector

> extend_insn_data, create_bb, move_block_to_fn logic has similar logic

> but implemented by hand.  Perhaps we can switch it to the new API.

> 

> combine_split_insns, combine_instructions, update_row_reg_save,

> grow_label_align, update_uses, final_warning_record::grow_type_warnings,

> sem_function::bb_dict_test, ::add_single_to_queue,

> symtab_node::create_reference, mark_phi_for_rewrite, addr_for_mem_ref,

> multiplier_allowed_in_address_p, get_address_cost_ainc,

> make_ssa_name_fn, add_to_value, phi_translate_1,

> optimize_range_tests_cmp_bitwise, set_strinfo,

> ssa_name_values.safe_grow_cleared, vect_record_loop_mask has similarly

> suspicious logic in it.


Are you talking about changing all '*gros*' calls to use exact=false, right?
I can experiment with that.

Martin

> 

> Honza

>>

>> I'm going to backport the patch older releases as well.

>>

>> Martin
Bill Schmidt via Gcc-patches July 27, 2020, 11:31 a.m. | #12
On Mon, Jul 27, 2020 at 1:24 PM Martin Liška <mliska@suse.cz> wrote:
>

> On 7/27/20 1:11 PM, Jan Hubicka wrote:

> >> On 7/27/20 9:11 AM, Richard Biener wrote:

> >>> OK.  I guess the previous code tried to use less memory.

> >>

> >> It did. But I didn't realize that such exact growth would lead

> >> to a massive reallocation for huge apps like chromium.

> >

> > I would consider it an API issue - it is not really at all that obvious

> > when vec API does auto reserve and when it does not.

>

> Fully agree here, it's super-confusing.

>

> >

> > Grepping for vec_safe_grow, rtl_create_basic_block, gimple_set_bb,

> > extend_h_i_d, stack_regs_mentioned, init_deps_data_vector

> > extend_insn_data, create_bb, move_block_to_fn logic has similar logic

> > but implemented by hand.  Perhaps we can switch it to the new API.

> >

> > combine_split_insns, combine_instructions, update_row_reg_save,

> > grow_label_align, update_uses, final_warning_record::grow_type_warnings,

> > sem_function::bb_dict_test, ::add_single_to_queue,

> > symtab_node::create_reference, mark_phi_for_rewrite, addr_for_mem_ref,

> > multiplier_allowed_in_address_p, get_address_cost_ainc,

> > make_ssa_name_fn, add_to_value, phi_translate_1,

> > optimize_range_tests_cmp_bitwise, set_strinfo,

> > ssa_name_values.safe_grow_cleared, vect_record_loop_mask has similarly

> > suspicious logic in it.

>

> Are you talking about changing all '*gros*' calls to use exact=false, right?

> I can experiment with that.


No, add gro*_exact variants and replace existing ones with this, then switch
to exact = false for the non-_exact variants.  Or add a exact=false argument
to all of them and make all existing calls explicitly passing true.

Only later, on a case by case basis, swap one for the other when obvious.

Richard.

> Martin

>

> >

> > Honza

> >>

> >> I'm going to backport the patch older releases as well.

> >>

> >> Martin

>
Andreas Schwab July 27, 2020, 12:49 p.m. | #13
On Jul 27 2020, Martin Liška wrote:

> @Andreas: Is it a known issue?


Which issue?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Bill Schmidt via Gcc-patches July 27, 2020, 12:51 p.m. | #14
On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>

> On Jul 27 2020, Martin Liška wrote:

>

> > @Andreas: Is it a known issue?

>

> Which issue?


I guess Martin means the checking glibc done looks excessive
(for the specific case of realloc). But yes, it's enabled in the build roots
so we just get what we ask for.

Richard.

> Andreas.

>

> --

> Andreas Schwab, schwab@linux-m68k.org

> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1

> "And now for something completely different."
Martin Liška July 27, 2020, 12:54 p.m. | #15
On 7/27/20 2:51 PM, Richard Biener wrote:
> On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab <schwab@linux-m68k.org> wrote:

>>

>> On Jul 27 2020, Martin Liška wrote:

>>

>>> @Andreas: Is it a known issue?

>>

>> Which issue?

> 

> I guess Martin means the checking glibc done looks excessive

> (for the specific case of realloc). But yes, it's enabled in the build roots

> so we just get what we ask for.


Yes. I'm basically curious who is this enabled/disabled for glibc.
I speak e.g. about:

#0  0x00007ffff7e886f0 in mem2chunk_check () from /lib64/libc.so.6
#1  0x00007ffff7e8cb8a in realloc_check () from /lib64/libc.so.6
#2  0x00005555555550bf in main (argc=<optimized out>, argv=<optimized out>) at bench.c:7

Martin

> 

> Richard.

> 

>> Andreas.

>>

>> --

>> Andreas Schwab, schwab@linux-m68k.org

>> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1

>> "And now for something completely different."
Bill Schmidt via Gcc-patches July 27, 2020, 12:58 p.m. | #16
On Mon, Jul 27, 2020 at 2:54 PM Martin Liška <mliska@suse.cz> wrote:
>

> On 7/27/20 2:51 PM, Richard Biener wrote:

> > On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab <schwab@linux-m68k.org> wrote:

> >>

> >> On Jul 27 2020, Martin Liška wrote:

> >>

> >>> @Andreas: Is it a known issue?

> >>

> >> Which issue?

> >

> > I guess Martin means the checking glibc done looks excessive

> > (for the specific case of realloc). But yes, it's enabled in the build roots

> > so we just get what we ask for.

>

> Yes. I'm basically curious who is this enabled/disabled for glibc.

> I speak e.g. about:

>

> #0  0x00007ffff7e886f0 in mem2chunk_check () from /lib64/libc.so.6

> #1  0x00007ffff7e8cb8a in realloc_check () from /lib64/libc.so.6

> #2  0x00005555555550bf in main (argc=<optimized out>, argv=<optimized out>) at bench.c:7


It's /etc/profile.d/malloc-debug.sh

> Martin

>

> >

> > Richard.

> >

> >> Andreas.

> >>

> >> --

> >> Andreas Schwab, schwab@linux-m68k.org

> >> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1

> >> "And now for something completely different."

>

Patch

diff --git a/gcc/symbol-summary.h b/gcc/symbol-summary.h
index a38eb1db778..fa1df5c8015 100644
--- a/gcc/symbol-summary.h
+++ b/gcc/symbol-summary.h
@@ -354,8 +354,11 @@  public:
        id = this->m_symtab->assign_summary_id (node);
  
      if ((unsigned int)id >= m_vector->length ())
-      vec_safe_grow_cleared (m_vector,
-			     this->m_symtab->cgraph_max_summary_id);
+      {
+	int newlen = this->m_symtab->cgraph_max_summary_id;
+	vec_safe_reserve (m_vector, newlen - m_vector->length ());
+	m_vector->quick_grow_cleared (newlen);
+      }
  
      if ((*m_vector)[id] == NULL)
        (*m_vector)[id] = this->allocate_new ();
@@ -812,7 +815,11 @@  public:
        id = this->m_symtab->assign_summary_id (edge);
  
      if ((unsigned)id >= m_vector->length ())
-      vec_safe_grow_cleared (m_vector, this->m_symtab->edges_max_summary_id);
+      {
+	int newlen = this->m_symtab->edges_max_summary_id;
+	m_vector->reserve (newlen - m_vector->length ());
+	m_vector->quick_grow_cleared (newlen);
+      }
  
      if ((*m_vector)[id] == NULL)
        (*m_vector)[id] = this->allocate_new ();
diff --git a/gcc/vec.h b/gcc/vec.h
index bd7c7351dcd..3ad99b83690 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -753,6 +753,17 @@  vec_safe_grow_cleared (vec<T, va_heap, vl_ptr> *&v,
    v->safe_grow_cleared (len PASS_MEM_STAT);
  }
  
+/* If V does not have space for NELEMS elements, call
+   V->reserve(NELEMS, EXACT).  */
+
+template<typename T>
+inline bool
+vec_safe_reserve (vec<T, va_heap, vl_ptr> *&v, unsigned nelems, bool exact = false
+		  CXX_MEM_STAT_INFO)
+{
+  return v->reserve (nelems, exact);
+}
+
  
  /* If V is NULL return false, otherwise return V->iterate(IX, PTR).  */
  template<typename T, typename A>