https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80911
--- Comment #17 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> Can't confirm that, running trunk@248556 works fine for me.
> Utilizing valgrind also does not help.
I also had problems reproducing the problem, so I decided to dig a little
further.
The problem occurred for me with g++ 4.4.3.
With a more recent g++ (5.4.0), we generate at gimplify:
...
D.67316 = {};
block_info::block_info (&D.67316);
try
{
D.74239 = gcov_read_unsigned ();
D.74240 = (long unsigned int) D.74239;
D.74241 = &fn->blocks;
std::vector<block_info>::resize (D.74241, D.74240, &D.67316);
}
finally
{
block_info::~block_info (&D.67316);
D.67316 = {CLOBBER};
}
...
In other words, before calling the default constructor block_info::block_info
on the implicit resize argument D.67316, we initialize it to zero using
'D.67316 = {}'.
With 4.4.3, we generate:
...
__comp_ctor (&D.67200);
try
{
D.67371 = gcov_read_unsigned ();
D.67372 = (long unsigned int) D.67371;
D.67373 = &fn->blocks;
resize (D.67373, D.67372, &D.67200);
}
finally
{
__comp_dtor (&D.67200);
}
...
and we don't initialize all of D.67200 to zero.
So, when compiling with a more recent compiler, the initialization is done
regardless of how the default constructor is implemented, so there's no problem
to detect with valgrind.
