From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25678 invoked by alias); 4 Mar 2013 17:51:53 -0000 Received: (qmail 25576 invoked by uid 48); 4 Mar 2013 17:51:16 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/56525] New: [4.8 Regression] Access to ggc_freed memory in flow_loops_find Date: Mon, 04 Mar 2013 17:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00276.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525 Bug #: 56525 Summary: [4.8 Regression] Access to ggc_freed memory in flow_loops_find Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned@gcc.gnu.org ReportedBy: jakub@gcc.gnu.org valgrind --track-origins=yes --leak-check=full --db-attach=yes ./cc1 /usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr54458.c -O3 -fomit-frame-pointer -o /tmp/x.s fails with: ==2723== Invalid read of size 8 ==2723== at 0x670584: flow_loops_find(loops*) (cfgloop.c:445) ==2723== by 0x8EC17E: fix_loop_structure(bitmap_head_def*) (loop-init.c:242) ==2723== by 0xAA5F93: repair_loop_structures() (tree-cfgcleanup.c:716) ==2723== by 0xAA602F: cleanup_tree_cfg() (tree-cfgcleanup.c:746) ==2723== by 0x977221: execute_function_todo(void*) (passes.c:1921) ==2723== by 0x97669A: do_per_function(void (*)(void*), void*) (passes.c:1701) ==2723== by 0x977476: execute_todo(unsigned int) (passes.c:1996) ==2723== by 0x977E86: execute_one_pass(opt_pass*) (passes.c:2344) ==2723== by 0x977FEB: execute_pass_list(opt_pass*) (passes.c:2378) ==2723== by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379) ==2723== by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379) ==2723== by 0x696413: expand_function(cgraph_node*) (cgraphunit.c:1640) ==2723== Address 0xb46b6f0 is not stack'd, malloc'd or (recently) free'd This happens after unswitching pass, where a loop is first ggc_freed: #1 0x00000000005fa4c8 in ggc_free (p=0x7ffff19896e8) at ../../gcc/ggc-page.c:1544 #2 0x000000000066fe08 in flow_loop_free (loop=0x7ffff19896e8) at ../../gcc/cfgloop.c:195 #3 0x00000000006721ca in delete_loop (loop=0x7ffff19896e8) at ../../gcc/cfgloop.c:1277 #4 0x00000000008ec13c in fix_loop_structure (changed_bbs=0x19162d0) at ../../gcc/loop-init.c:234 #5 0x0000000000aa5f94 in repair_loop_structures () at ../../gcc/tree-cfgcleanup.c:716 #6 0x0000000000aa6030 in cleanup_tree_cfg () at ../../gcc/tree-cfgcleanup.c:746 and then used in flow_loops_find: 443 /* The current active loop tree has valid loop-fathers for 444 header blocks. */ 445 if (!from_scratch 446 && header->loop_father->header == header) When not under valgrind, header->loop_father->header will be typically 0xafafafafafafafaf, so won't match and show that it indeed does something wrong.