public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined Date: Mon, 17 Mar 2014 14:04:00 -0000 [thread overview] Message-ID: <bug-60535-4-ETtiUMaKLd@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60535-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 32373 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32373&action=edit gcc49-pr60535.patch Untested fix. There are 3 remaining tests I haven't removed the dg-skip-if for yet: c-c++-common/ubsan/null-4.c c-c++-common/ubsan/overflow-int128.c These 2 fail because with -flto we get <unknown> type names instead of say complex double or int128_t (if I remember it well). Dunno if there is anything that can be done about it though. g++.dg/ubsan/pr59437.C This one shows a bug either in the -fvtable-* verification stuff, or in cgraph, but doesn't look related to ubsan: ==27993== Invalid write of size 8 ==27993== at 0x89AEEC: bitmap_initialize_stat(bitmap_head*, bitmap_obstack*) (bitmap.h:277) ==27993== by 0x89BA7C: bitmap_obstack_alloc_stat(bitmap_obstack*) (bitmap.c:376) ==27993== by 0xDCB7B2: mark_def_dom_walker::mark_def_dom_walker(cdi_direction) (tree-into-ssa.c:2234) ==27993== by 0xDCBA80: rewrite_into_ssa() (tree-into-ssa.c:2331) ==27993== by 0xDCBD70: (anonymous namespace)::pass_build_ssa::execute() (tree-into-ssa.c:2403) ==27993== by 0xC56F9D: execute_one_pass(opt_pass*) (passes.c:2229) ==27993== by 0xC571B6: execute_pass_list(opt_pass*) (passes.c:2282) ==27993== by 0xC4B58E: gcc::pass_manager::execute_early_local_passes() (passes.c:135) ==27993== by 0x92BCA4: cgraph_process_new_functions() (cgraphunit.c:338) ==27993== by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993== by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993== by 0xD42091: compile_file() (toplev.c:562) ==27993== Address 0xbc0cdf0 is 96 bytes inside a block of size 4,064 free'd ==27993== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27993== by 0x3C5FA84857: obstack_free (in /usr/lib64/libc-2.18.so) ==27993== by 0x89B901: bitmap_obstack_release(bitmap_obstack*) (bitmap.c:358) ==27993== by 0x92C95C: analyze_function(cgraph_node*) (cgraphunit.c:665) ==27993== by 0x92BC0B: cgraph_process_new_functions() (cgraphunit.c:334) ==27993== by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993== by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993== by 0xD42091: compile_file() (toplev.c:562) ==27993== by 0xD441E9: do_compile() (toplev.c:1914) ==27993== by 0xD44354: toplev_main(int, char**) (toplev.c:1990) ==27993== by 0x14BD71B: main (main.c:36) Apparently this is related to the default obstack freeing and use after free, either vtable*.c calls cgraph at a pointer where it is not supposed to (or needs to conditionalize it on cgraph_state), or cgraph doesn't handle nesting properly.
next prev parent reply other threads:[~2014-03-17 14:04 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-03-15 9:22 [Bug other/60535] New: [4.9 Regression] " trippels at gcc dot gnu.org 2014-03-17 9:46 ` [Bug sanitizer/60535] " rguenth at gcc dot gnu.org 2014-03-17 10:58 ` jakub at gcc dot gnu.org 2014-03-17 11:04 ` mpolacek at gcc dot gnu.org 2014-03-17 13:09 ` [Bug sanitizer/60535] " trippels at gcc dot gnu.org 2014-03-17 14:04 ` jakub at gcc dot gnu.org [this message] 2014-03-17 14:14 ` rguenth at gcc dot gnu.org 2014-03-17 14:36 ` mpolacek at gcc dot gnu.org 2014-03-18 14:57 ` jakub at gcc dot gnu.org 2014-03-18 15:03 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-60535-4-ETtiUMaKLd@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).