public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mikpe at it dot uu dot se" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/39429] compiler create bad asm codes. Date: Mon, 13 Jul 2009 13:06:00 -0000 [thread overview] Message-ID: <20090713130555.25390.qmail@sourceware.org> (raw) In-Reply-To: <bug-39429-17427@http.gcc.gnu.org/bugzilla/> ------- Comment #8 from mikpe at it dot uu dot se 2009-07-13 13:05 ------- Mystery solved. Buried in revision 146451, which should just fix enum conversions for C++ compatibility, is the following bug fix: --- trunk/gcc/config/arm/arm.c 2009/04/20 19:30:55 146450 +++ trunk/gcc/config/arm/arm.c 2009/04/20 19:35:00 146451 @@ -7408,7 +7410,7 @@ /* Don't accept any offset that will require multiple instructions to handle, since this would cause the arith_adjacentmem pattern to output an overlong sequence. */ - if (!const_ok_for_op (PLUS, val0) || !const_ok_for_op (PLUS, val1)) + if (!const_ok_for_op (val0, PLUS) || !const_ok_for_op (val1, PLUS)) return 0; /* Don't allow an eliminable register: register elimination can make The parameters to const_ok_for_op had been swapped, causing this if statement to not reject offsets that are awkward for ARM. Combined with a non-FL_LDSCHED cpu type this enabled arith_adjacentmem for a bad offset, which forced it to split the LDM into two LDRs, and that code fails to order the LDRs to avoid clobbering the shared base register. With the above patch arith_adjacentmem will not trigger for bad offsets, avoiding the broken LDM splitting code. This patch is needed also for the 4.4 and 4.3 branches, and I've checked that it fixes this test case there too. It seems that there is a bit of redundancy between the adjacent_mem_locations test and the arith_adjacentmem pattern. Both check const_ok_for_arm on the offset and the negated offset. The first attempts to reject bad offsets, while the second attempts to handle them. I'm not sure, but I _think_ that the code in arith_adjacentmem to split an LDM into two LDRs is now dead (after the bug fix above). However, just in case it isn't, I'm attaching a patch to correct it. Unrelated to this PR, buried in revision 146451 is another bug fix: --- trunk/gcc/config/arm/arm.c 2009/04/20 19:30:55 146450 +++ trunk/gcc/config/arm/arm.c 2009/04/20 19:35:00 146451 @@ -5465,7 +5465,7 @@ return true; case ABS: - if (GET_MODE_CLASS (mode == MODE_FLOAT)) + if (GET_MODE_CLASS (mode) == MODE_FLOAT) { if (TARGET_HARD_FLOAT && (mode == SFmode || mode == DFmode)) { This one is also needed in 4.4, but not in 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
next prev parent reply other threads:[~2009-07-13 13:06 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-03-11 7:25 [Bug c++/39429] New: " ryos at sinby dot com 2009-03-12 1:19 ` [Bug c++/39429] " ryos at sinby dot com 2009-03-16 22:53 ` rearnsha at gcc dot gnu dot org 2009-03-16 23:02 ` [Bug target/39429] " rearnsha at gcc dot gnu dot org 2009-07-11 20:20 ` mikpe at it dot uu dot se 2009-07-12 11:30 ` mikpe at it dot uu dot se 2009-07-12 20:51 ` ramana at gcc dot gnu dot org 2009-07-12 21:21 ` mikpe at it dot uu dot se 2009-07-12 23:58 ` mikpe at it dot uu dot se 2009-07-13 13:06 ` mikpe at it dot uu dot se [this message] 2009-07-13 13:07 ` mikpe at it dot uu dot se [not found] <bug-39429-4@http.gcc.gnu.org/bugzilla/> 2015-03-12 11:29 ` ramana 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=20090713130555.25390.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).