On 05/20/2015 10:41 AM, Jakub Jelinek wrote:
On Wed, May 20, 2015 at 10:36:25AM -0600, Jeff Law wrote:
These fix the remaining leaks in the threader that I'm aware of. We failed
to properly clean-up when we had to cancel certain jump threading
opportunities. So thankfully this wasn't a big leak.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Installed on
the trunk.
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fe4dfc4..27435c6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2015-05-20 Jeff Law <l...@redhat.com>
+
+ * tree-ssa-threadupdate.c (mark_threaded_blocks): Properly
+ dispose of the jump thread path when the jump threading
+ opportunity is cancelled.
+
2015-05-20 Manuel López-Ibáñez <m...@gcc.gnu.org>
* diagnostic.c (diagnostic_print_caret_line): Fix off-by-one error
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index c5b78a4..4bccad0 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2159,9 +2159,16 @@ mark_threaded_blocks (bitmap threaded_blocks)
{
/* Attach the path to the starting edge if none is yet recorded. */
if ((*path)[0]->e->aux == NULL)
- (*path)[0]->e->aux = path;
- else if (dump_file && (dump_flags & TDF_DETAILS))
- dump_jump_thread_path (dump_file, *path, false);
+ {
+ (*path)[0]->e->aux = path;
+ }
Why the braces around single stmt if body?
To match what was happening in the else clause. I always find
if (fubar)
something
else
{
more stuff
even more stuff
}
more painful to parse because of the mis-matched indentation than
if (fubar)
{
something
}
else
{
more stuff
even more stuff
}
It's purely a style thing and if you'd prefer not to have the extra
braces, I wouldn't lose any sleep over removing them.
Also, the indentation seems to be weird.
Looks like spaces vs tabs issue. I'll do a pass over
tree-ssa-threadedge.c and fix them all up at once.
jeff