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 tree-optimization/55920] ICE in expand_debug_locations, at cfgexpand.c:3753 Date: Wed, 09 Jan 2013 17:47:00 -0000 [thread overview] Message-ID: <bug-55920-4-xsa5vqqt6K@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-55920-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-09 17:47:08 UTC --- Seems the bug is that the DEBUG stmt created by SRA has <var_decl 0x7ffff19a4e40 from$s_addr type <integer_type 0x7ffff1996690 unsigned int sizes-gimplified asm_written public unsigned SI as the first operand, but <mem_ref 0x7ffff17e0f78 type <record_type 0x7ffff17df1f8 in_addr sizes-gimplified asm_written no-force-blk packed type_0 BLK as the second operand (note the first one is SImode, the latter BLKmode). Perhaps the packed attribute is what causes this, dunno. But we probably just shouldn't emit a debug stmt if the mode is different, unless we can e.g. use a COMPONENT_REF on it to get at the right mode. Also, as the aggregate is actually used (in the call stmt a few stmts later), I'd say SRA shouldn't emit the debug stmts for it at all, ideally for PR55579 we'd emit those only either if we'd SRA it anyway in the code (disregarding debug), or if we have just stores but no uses of the aggregate. Right now on trunk every SRA pass adds another set of debug stmts, because the aggregate assignments aren't DCEd (as they are used). Looking at this, perhaps we should defer PR55579 resolution for stage1 of 4.9, so we have more time to e.g. think about some size limits what we still emit as debug stmts and what not, etc. Martin, what are your thoughts?
next prev parent reply other threads:[~2013-01-09 17:47 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-09 16:30 [Bug tree-optimization/55920] New: " rmansfield at qnx dot com 2013-01-09 17:47 ` jakub at gcc dot gnu.org [this message] 2013-01-09 18:23 ` [Bug tree-optimization/55920] [4.8 Regression] " rguenth at gcc dot gnu.org 2013-01-11 16:53 ` jamborm at gcc dot gnu.org 2013-01-11 16:56 ` jamborm at gcc dot gnu.org 2013-01-11 17:05 ` jakub at gcc dot gnu.org 2013-01-15 12:04 ` jakub at gcc dot gnu.org 2013-01-15 12:19 ` jamborm at gcc dot gnu.org 2013-01-15 16:34 ` jakub at gcc dot gnu.org 2013-01-15 16:43 ` jamborm at gcc dot gnu.org 2013-01-15 18:37 ` 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-55920-4-xsa5vqqt6K@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).