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 target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test Date: Sun, 11 Jul 2010 16:24:00 -0000 [thread overview] Message-ID: <20100711162349.30339.qmail@sourceware.org> (raw) In-Reply-To: <bug-44903-276@http.gcc.gnu.org/bugzilla/> ------- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-11 16:23 ------- (In reply to comment #5) > Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c > execution test > > On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote: > > > > > > > ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-11 10:47 ------- > > (In reply to comment #3) > > > Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c > > > execution test > > > > > > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote: > > > > > > > I get for all memory accesses an alignment of 8 at expansion time which looks > > > > correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos > > > > looks conservative enough. > > > > > > The rtl in question is the following: > > > > > > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI > > > 28 %r28 [orig:94 D.1980 ] [94]) > > > (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95]) > > > (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str + > > > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil)) > > > > > > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets > > > that define STRICT_ALIGNMENT. We need an alignment of 32. > > > > > > I believe the i?86 hardware allows unaligned addresses, so you wouldn't > > > see the problem. > > > > Hm. So the MEM_REF path goes the same way as the INDIRECT_REF path for > > > > typedef int t __attribute__((aligned(1),may_alias)); > > int foo(t *p) > > { > > return *p; > > } > > int main() > > { > > char c[5] = {}; > > if (foo(&c[1]) != 0) > > abort (); > > return 0; > > } > > > > for example on the 4.5 branch. I see no provision to handle not properly > > aligned pointer dereferences in expansion. So I believe this is a latent > > issue - but I am quite lost here in the myriads of RTL expansion (which > > isn't exactly a piece of GCC I am familiar with). > > Yes, I don't believe that there ever was a general provision to handle > improperly aligned pointer dereferences in expansion. However, I think > memcpy was special. In the above case the int type the pointer points to is specified as being unaligned, so the testcase is valid. > > But back to the above testcase. On the 4.5 branch I get on i?86: > > > > (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ]) > > (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil)) > > > > (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around) > > > > (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341) > > (unspec:DI [ > > (reg:SI 342) > > ] 24)) -1 (nil)) > > > > (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ]) > > (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil)) > > > > thus an alignment of 32!? A nice way of "fixing" ;) > > > > I am curious if the above testcase works for you on the 4.5 branch (or > > for any version). > > The test always passed before. I've attached the .expand file generated using > the 4.5 branch (32-bit) for comparison. The above testcase worked? Not the pr35258.c, but the one I gave, with the int aligned(1)? The difference on the 4.5 branch is that we left the memcpy call alone and did not inline-expand it on the tree level. I am trying to say that we hit a latent bug here, and that it's finally time to fix it (but I don't easily see how to do that in the most efficient way). > Dave -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2010-07-11 16:23:49 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
next prev parent reply other threads:[~2010-07-11 16:24 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-10 15:17 [Bug tree-optimization/44903] New: " danglin at gcc dot gnu dot org 2010-07-10 19:46 ` [Bug tree-optimization/44903] [4.6 Regression] " danglin at gcc dot gnu dot org 2010-07-10 21:29 ` [Bug target/44903] " rguenth at gcc dot gnu dot org 2010-07-10 23:35 ` dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 10:47 ` rguenth at gcc dot gnu dot org 2010-07-11 15:17 ` dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 16:24 ` rguenth at gcc dot gnu dot org [this message] 2010-07-11 16:33 ` danglin at gcc dot gnu dot org 2010-07-11 16:55 ` dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 22:04 ` rguenth at gcc dot gnu dot org 2010-07-11 22:22 ` dave at hiauly1 dot hia dot nrc dot ca 2010-07-11 22:37 ` rguenth at gcc dot gnu dot org 2010-07-13 13:53 ` rguenth at gcc dot gnu dot org 2010-07-13 17:41 ` mikpe at it dot uu dot se 2010-07-14 0:19 ` danglin at gcc dot gnu dot org 2010-07-23 12:14 ` rguenth at gcc dot gnu dot org 2010-07-26 12:22 ` rguenth at gcc dot gnu dot org 2010-07-26 12:45 ` rguenth at gcc dot gnu dot org 2010-07-26 12:46 ` rguenth at gcc dot gnu dot org 2010-07-28 0:22 ` dave at hiauly1 dot hia dot nrc dot ca 2010-07-28 10:33 ` rguenth at gcc dot gnu dot org 2010-07-28 10:33 ` rguenth 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=20100711162349.30339.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).