Okay to backport c00568f376078129196740d83946d54dc5437401 to the GCC 9
branch, Jakub?
Thanks,
Gerald
On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated and when its dtor
> is called it calls delete on uninitialized data, causing an ICE.
>
> It happens when a temporary dump_context is instantiated for the 'm_saved'
> initialization in temp_dump_context::temp_dump_context. In that case it
> might happen that that temporary dump_context is not initalized properly
> and when it gets destroyed its dtor tries to delete 'm_pending', (delete an
> uninitialized optinfo *), thus calling delete on an uninitialized memory,
> or on whatever happens to be in the stack, generating an ICE.
>
> This commit fixes that issue by using singleton's static member get()
> directly to get the singleton's active instance, which doesn't instantiate
> a new class, so no dtor is called.
>
> gcc/Changelog:
> 2020-04-06 Gustavo Romero <grom...@linux.ibm.com>
>
> * dumpfile.c:
> (selftest::temp_dump_context::temp_dump_context): Fix ctor.
> ---
> gcc/dumpfile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
> index 468ffab..e392ecf 100644
> --- a/gcc/dumpfile.c
> +++ b/gcc/dumpfile.c
> @@ -2076,7 +2076,7 @@ temp_dump_context::temp_dump_context (bool
> forcibly_enable_optinfo,
> bool forcibly_enable_dumping,
> dump_flags_t test_pp_flags)
> : m_context (),
> - m_saved (&dump_context ().get ())
> + m_saved (&dump_context::get ())
> {
> dump_context::s_current = &m_context;
> if (forcibly_enable_optinfo)
>
