This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR80721
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, meisenmann dot lba at fh-salzburg dot ac dot at
- Date: Fri, 12 May 2017 12:07:06 +0100
- Subject: Re: [PATCH] Fix PR80721
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7855980C23
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7855980C23
- References: <alpine.LSU.2.20.1705121203560.20726@zhemvz.fhfr.qr>
On 12/05/17 12:10 +0200, Richard Biener wrote:
It was pointed out by Markus that the EH emergency pool is not
kept sorted and fully merged properly for the cases of freeing
an entry before the first free entry and for the cases where
merging with the immediate successor and for the case with
merging with both successor and predecessor is possible.
The following patch attempts to fix this.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Ok for trunk? (given low / close to no testing coverage
extra close eyes wanted!)
Reporter says maybe it can't happen in real-life as it requires
EH deallocation order not be the reverse of allocation order.
I don't know enough here for a quick guess but "in C++ everything
is possible" ;)
It's definitely possible.
std::exception_ptr p1, p2;
try {
throw 1;
} catch (...) {
p1 = std::current_exception();
}
try {
throw 2;
} catch (...) {
p2 = std::current_exception();
}
Both exceptions are still active, and their lifetimes are now tied to
value objects which can be reset, swapped, copied etc. so their
lifetime is now arbitrary.