From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id 87B5C385840B
 for <gcc-patches@gcc.gnu.org>; Mon, 29 Nov 2021 18:19:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 87B5C385840B
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 39DCC280872; Mon, 29 Nov 2021 19:19:13 +0100 (CET)
Date: Mon, 29 Nov 2021 19:19:13 +0100
From: Jan Hubicka <hubicka@kam.mff.cuni.cz>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] ipa-param-manip: Be careful about a reallocating
 hash_map (PR 103449)
Message-ID: <20211129181913.GB63439@kam.mff.cuni.cz>
References: <ri68rx6hlmi.fsf@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ri68rx6hlmi.fsf@suse.cz>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
 SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 18:19:16 -0000

> Hi,
> 
> PR 103449 revealed that when I was storing result of one hash_map
> lookup into another entry in the hash_map, I was still accessing the
> entry in the table, which meanwhile could get reallocated, making the
> accesses invalid-after-free.
> 
> Fixed with the following, which also simplifies the return statement
> which must have been true even now.
> 
> Bootstrapped and tested on x86_64-linux.  OK for master?
> 
> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2021-11-29  Martin Liska  <mliska@suse.cz>
> 	    Martin Jambor  <mjambor@suse.cz>
> 
> 	PR ipa/103449
> 	* ipa-param-manipulation.c
> 	(ipa_param_body_adjustments::prepare_debug_expressions): Be
> 	careful about hash_map reallocating itself.  Simpify a return
> 	which always returns true.
OK, thanks!
Honza