public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475 Date: Mon, 19 Jul 2010 12:47:00 -0000 [thread overview] Message-ID: <20100719124728.19650.qmail@sourceware.org> (raw) In-Reply-To: <bug-44972-6008@http.gcc.gnu.org/bugzilla/> ------- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-19 12:47 ------- Well, the list of problems is endless it seems - we are not consistent in how we build accesses for declD.1.u1.a.align = 13; vs. decl$u1$a$align_5 = BIT_FIELD_REF <MEM[(<unnamed-unsigned:24> *)&declD.2], 24, 0>; (the former is a COMPONENT_REF with DECL_BIT_FIELD while the latter is a BIT_FIELD_REF. The first access will be [0, 24] while the later [0, 32]. This causes us to scalarize declD.2 = declD.1; as declD.2 = declD.2; because we cannot find a matching access in load_assign_lhs_subreplacements and drop into the strange code for SRA_UDH_LEFT. So eventually we should not drop bit-field-ref kind outer accesses in favor of handling them as partial_ref or we should do the same for DECL_BIT_FIELD component-refs. I'm a bit lost and will attach the current WIP patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
next prev parent reply other threads:[~2010-07-19 12:47 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-17 13:46 [Bug tree-optimization/44972] New: " marc dot glisse at normalesup dot org 2010-07-17 13:48 ` [Bug tree-optimization/44972] " marc dot glisse at normalesup dot org 2010-07-17 18:07 ` [Bug tree-optimization/44972] [4.6 Regression] " hjl dot tools at gmail dot com 2010-07-17 18:49 ` marc dot glisse at normalesup dot org 2010-07-18 17:51 ` rguenth at gcc dot gnu dot org 2010-07-18 20:57 ` rguenth at gcc dot gnu dot org 2010-07-18 21:11 ` rguenth at gcc dot gnu dot org 2010-07-18 21:22 ` rguenth at gcc dot gnu dot org 2010-07-19 12:47 ` rguenth at gcc dot gnu dot org [this message] 2010-07-19 12:49 ` rguenth at gcc dot gnu dot org 2010-07-22 18:29 ` jamborm at gcc dot gnu dot org 2010-07-23 19:15 ` jamborm at gcc dot gnu dot org 2010-08-08 18:31 ` jamborm at gcc dot gnu dot org 2010-08-08 18:39 ` jamborm at gcc dot gnu dot org 2010-09-02 10:57 ` rguenth at gcc dot gnu dot org 2010-09-08 17:01 ` jamborm at gcc dot gnu dot org 2010-09-09 23:28 ` jamborm at gcc dot gnu dot org 2010-09-09 23:38 ` jamborm at gcc dot gnu dot org 2010-09-09 23:41 ` jamborm at gcc dot gnu dot 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=20100719124728.19650.qmail@sourceware.org \ --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).