[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-04-13 10:29 --- *** Bug 43744 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #36 from chrbr at gcc dot gnu dot org 2010-02-10 12:02 --- (In reply to comment #33) > Your fix of the middle end looks plausible but I think the target > shouldn't generate a CP at the eh landing pad anyway. I'll commit > the hunk below anyway after your patch for pic problem is installed. > done, you can commit your w/a. > @@ -4654,6 +4654,13 @@ find_barrier (int num_mova, rtx mova, rt >if (last_got) > from = PREV_INSN (last_got); > > + /* Don't insert the constant pool table at the position which > +may be the landing pad. */ > + if (flag_exceptions > + && CALL_P (from) > + && find_reg_note (from, REG_EH_REGION, NULL_RTX)) > + from = PREV_INSN (from); > + >/* Walk back to be just before any jump or label. > Putting it before a label reduces the number of times the branch > around the constant pool table will be hit. Putting it before > -- chrbr at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #35 from kkojima at gcc dot gnu dot org 2010-02-05 21:54 --- (In reply to comment #34) > I was expecting that the landing pad was > a good place for the constant pool on the contrary. I thought so too. But on second thought, it'd be a bit surprising for the non CP world and may cause similar problems. We should be defensive in this regard, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #34 from chrbr at gcc dot gnu dot org 2010-02-05 08:26 --- (In reply to comment #33) > Your fix of the middle end looks plausible but I think the target > shouldn't generate a CP at the eh landing pad anyway. I'll commit > the hunk below anyway after your patch for pic problem is installed. > OK. I didn't check the code quality difference between the middle-end fix and yours. Since there are no fallthru to the landing pad, and locality with the upcoming exception region is not important, (if we suppose that the exception handler is not on the critical path), I was expecting that the landing pad was a good place for the constant pool on the contrary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #33 from kkojima at gcc dot gnu dot org 2010-02-05 07:42 --- Your fix of the middle end looks plausible but I think the target shouldn't generate a CP at the eh landing pad anyway. I'll commit the hunk below anyway after your patch for pic problem is installed. @@ -4654,6 +4654,13 @@ find_barrier (int num_mova, rtx mova, rt if (last_got) from = PREV_INSN (last_got); + /* Don't insert the constant pool table at the position which +may be the landing pad. */ + if (flag_exceptions + && CALL_P (from) + && find_reg_note (from, REG_EH_REGION, NULL_RTX)) + from = PREV_INSN (from); + /* Walk back to be just before any jump or label. Putting it before a label reduces the number of times the branch around the constant pool table will be hit. Putting it before -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #32 from chrbr at gcc dot gnu dot org 2010-02-05 07:05 --- > Looks smart and clean! One minor nit, I guess that the occurence of > gbr and GBR in ChangeLog and comments should be replaced with GOT to > avoid confusion with GBR register of SH CPU. Thanks for catching up this error in the comment. I meant GP of course, which is even more preferable that GOT (which is what we load, not what we compute). (In reply to comment #31) > When you propose it to the list, could you please separate the third > hunk which is for the original PR42841 as an independant patch. Also > don't forget to update the copyright years in the first one. > OK, that was also my intention to submit the 3rd hunk (the one that fixes the jump to the landing pad around the constant table right ?) as a separate patch as it will require the approval of a middle end maintainer. If it cannot go in the trunk before the 4.5 freeze I can propose you to commit your workaround (comment #23) so not to block the regression. Then we can revert when the proper patch is discussed/accepted. (I'm a little bit late for that sorry). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #31 from kkojima at gcc dot gnu dot org 2010-02-04 22:42 --- Looks smart and clean! One minor nit, I guess that the occurence of gbr and GBR in ChangeLog and comments should be replaced with GOT to avoid confusion with GBR register of SH CPU. When you propose it to the list, could you please separate the third hunk which is for the original PR42841 as an independant patch. Also don't forget to update the copyright years in the first one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #30 from chrbr at gcc dot gnu dot org 2010-02-03 13:12 --- Created an attachment (id=19794) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794&action=view) patch to fix GOT access load with constant pool Patch under validation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #29 from kkojima at gcc dot gnu dot org 2010-02-03 10:06 --- I think these blockages are not overkill. GOTaddr2picreg is used only at prologue and non-pic tls initial exec accesses. The former is at most once for each function and never in the minor loop. The latter case wouldn't occur so frequently and the initial exec access is loaded sequence of instructions in the first place. > We only want to avoid the CP to be inserted between those 2 instructions, > it's not necessary to have more blockages. I'm working on something that > tracks the GOT loading access during the find_barrier walk and then revert > back at the end to the latest safe place. OK on the example but the full > linux distrib rebuild and validation is still ongoing. Of course, it's OK if it passes all the usual tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #28 from chrbr at gcc dot gnu dot org 2010-02-03 08:30 --- Hello Kaj, thanks for your proposal thanks for the proposal. but I'm wondering if preventing the scheduling of the mov.l and mova instructions are not too much overkill ? (sh_reorg comes after the scheduler, but even if it didn't that should be ok to mov up instructions. (the R0 liverange between the add and load is another more general problem) Do I miss something ? We only want to avoid the CP to be inserted between those 2 instructions, it's not necessary to have more blockages. I'm working on something that tracks the GOT loading access during the find_barrier walk and then revert back at the end to the latest safe place. OK on the example but the full linux distrib rebuild and validation is still ongoing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #27 from kkojima at gcc dot gnu dot org 2010-02-02 22:16 --- Created an attachment (id=19792) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19792&action=view) A patch Indeed! I've tested the attached patch and confirmed that it doesn't regress with the top level "make -k check" for all languages except ada on sh4-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #26 from chrbr at gcc dot gnu dot org 2010-02-01 16:30 ---
I'm afraid the unaligned access sigbug regression is another latent bug just
exhibited by the fix for the original PR :-(
what happens is the the GOT loading sequence is broken by a constant pool:
we end up to emit:
mov.l .L542,r12(X)
bra .L516
nop
.L542:
.align 2
.long _GLOBAL_OFFSET_TABLE_
...
.L516:
mova.L545,r0 (Y) !
add r0,r12
.L545:
.long _GLOBAL_OFFSET_TABLE_
The reason for that is that the second mova instruction is unluckily now out of
range by 2 bytes. (which could happen with any other situation, even without
this patch).
IMHO We should forbid the duplication of a _GLOBAL_OFFSET_TABLE_ loading
constant while in a UNSPEC_MOVA sequence.
We should probably reduce si_limit in find_barrier when a
(set (reg:SI 0 r0)
(unspec:SI [
(const:SI (unspec:SI [
(symbol_ref ("*_GLOBAL_OFFSET_TABLE_"))
is met and next is
(set (reg:SI 12 r12)
(const:SI (unspec:SI [
(symbol_ref ("*_GLOBAL_OFFSET_TABLE_")
in PIC.
I experimenting with a couple of different solutions in this direction.
this PR was a really interesting bugs finder !
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #25 from chrbr at gcc dot gnu dot org 2010-01-29 08:59 --- by the way, FYI, trying to explain the differences between your results and mine for sh4-linux. my build was is configured with --enable-target-optspace, so all my runtime build tests are ran with -Os, not -O2 like yours. Which could make a huge differences in CP layout... I repass in -O2 over the week end. Cheers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #24 from chrbr at gcc dot gnu dot org 2010-01-29 07:46 --- Created an attachment (id=19747) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19747&action=view) fixed removal of landing pad label rtx The landing_pad label rtx was created and recorded in tree_inline (duplicate_eh_regions). Seems that reorg_redirect_jump or delete_insn should check for it before deciding it can be removed. I'm testing this patch that does this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #23 from kkojima at gcc dot gnu dot org 2010-01-29 02:19 --- I agree with you that there is a latent problem. It seems that sh_reorg inserts a CP with a new jump at the landing pad for the exception in basic.cc and propagation_consistent.cc cases. This confuses EH processing because the labels for landing pads are defined and recorded very early and used later to output DW2 frame data, unfortunately. A simple work around may be not to insert a jump+CP at the possible position for the landing pad. The patch --- ORIG/trunk/gcc/config/sh/sh.c 2010-01-26 18:33:47.0 +0900 +++ trunk/gcc/config/sh/sh.c2010-01-29 09:56:50.0 +0900 @@ -4641,6 +4641,9 @@ find_barrier (int num_mova, rtx mova, rt a jump makes it more likely that the bra delay slot will be filled. */ while (NOTE_P (from) || JUMP_P (from) +|| (flag_exceptions +&& CALL_P (from) +&& find_reg_note (from, REG_EH_REGION, NULL_RTX)) || LABEL_P (from)) from = PREV_INSN (from); fixes the failures for basic.cc and propagation_consistent.cc, though it doesn't fix the execution failures for get_future.cc and get.cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #22 from chrbr at gcc dot gnu dot org 2010-01-28 13:09 --- humm, looks like a latent bug. Accidentally the CP is inserted before a compact_jump, which enable further redirect jump optimisation. I don't think it is directly related to the fix, but lets work it a little bit more. so we have just before dbr: jump_insn -> 2586 a constant pool L2586 jump_insn -> 3394 L3394: ... then in reorg_redirect_jump we redirect the jump over the CP and delete_related_insn so the code between the CP and the jump becomes dead. and we have jump_insn -> 3394 a constant pool L3394 ... but the label L2586 is used in the exception table... and thus remains undefined. now my question: how the exception table can refer to a region delimited by deleted labels. It's should be built after dbr isn't it ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #21 from chrbr at gcc dot gnu dot org 2010-01-27 18:13 --- This one is marked as unsupported in my sh-superh-elf log, But I can reproduce it now on sh4-linux. (despite that I have rebuilt a whole distrib without seeing it :O). Anyway I'm investigating. I'm reopening the bug and will revert in the branches as well if I don't find a quick solution. Regards (In reply to comment #20) > Created an attachment (id=19729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19729&action=view) [edit] > A test case > > "cc1plus -std=gnu++0x -O2 propagation_consistent.ii" produces > a problematic code here. > -- chrbr at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #20 from kkojima at gcc dot gnu dot org 2010-01-27 14:08 --- Created an attachment (id=19729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19729&action=view) A test case "cc1plus -std=gnu++0x -O2 propagation_consistent.ii" produces a problematic code here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #19 from chrbr at gcc dot gnu dot org 2010-01-27 13:40 --- to make sure we are in the same testing/configuration environment could you please send me the preprocessed file for 23_containers/deque/requirements/exception/propagation_consistent.cc as well as the compilation line in libstdc++.log that you used ? many thanks Christian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #18 from chrbr at gcc dot gnu dot org 2010-01-27 13:24 --- Subject: Bug 42841 Author: chrbr Date: Wed Jan 27 13:24:40 2010 New Revision: 156282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156282 Log: temporarily revert fix for PR target/42841 Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #17 from chrbr at gcc dot gnu dot org 2010-01-27 12:50 --- strange, I didn't see that, even the undefined symbol in the assembler. OK I disable the fix until this is clarified. Let me do a recheck on the silicium, will let you know. -c (In reply to comment #16) > I've got some new libstdc++-v3 testsuite failures with the patch > on my nightly sh4-linux tester: > > Running > /exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp > ... > FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess > errors) > WARNING: 23_containers/deque/requirements/exception/basic.cc compilation > failed > to produce executable > FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc > (test for excess errors) > WARNING: 23_containers/deque/requirements/exception/propagation_consistent.cc > compilation failed to produce executable > FAIL: 30_threads/packaged_task/members/get_future.cc execution test > FAIL: 30_threads/shared_future/members/get.cc execution test > > The first failure is > > /tmp/ccl5TCl4.s: Assembler messages: > /tmp/ccl5TCl4.s:43070: Error: undefined symbol `.L3394' in operation > > FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess > errors) > > The last 2 failures are resulted with the unaligned accesses. I saw > > Sending SIGBUS to "get_future.exe" due to unaligned access (PC 296554a8 PR > 2965549a) > Sending SIGBUS to "get.exe" due to unaligned access (PC 296554a8 PR 2965549a) > > on the target machine. > With reverting the first hunk of the patch, these errors go away. > Christian, could you please revert or disable the first hunk > of patches temporarily? Sorry I didn't catch this earlier. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #16 from kkojima at gcc dot gnu dot org 2010-01-27 12:32 --- I've got some new libstdc++-v3 testsuite failures with the patch on my nightly sh4-linux tester: Running /exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/basic.cc compilation failed to produce executable FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc (test for excess errors) WARNING: 23_containers/deque/requirements/exception/propagation_consistent.cc compilation failed to produce executable FAIL: 30_threads/packaged_task/members/get_future.cc execution test FAIL: 30_threads/shared_future/members/get.cc execution test The first failure is /tmp/ccl5TCl4.s: Assembler messages: /tmp/ccl5TCl4.s:43070: Error: undefined symbol `.L3394' in operation FAIL: 23_containers/deque/requirements/exception/basic.cc (test for excess errors) The last 2 failures are resulted with the unaligned accesses. I saw Sending SIGBUS to "get_future.exe" due to unaligned access (PC 296554a8 PR 2965549a) Sending SIGBUS to "get.exe" due to unaligned access (PC 296554a8 PR 2965549a) on the target machine. With reverting the first hunk of the patch, these errors go away. Christian, could you please revert or disable the first hunk of patches temporarily? Sorry I didn't catch this earlier. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||christian dot bruel at st ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #15 from iwamatsu at nigauri dot org 2010-01-26 23:54 --- (In reply to comment #10) > (In reply to comment #9) > > So I took the opportunity to cleanup every other > > occurrences of the same idioms in the file. OK ? > > OK. Thanks! > Thanks for your patch! I confirmed that problem on other program was fixed with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #14 from chrbr at gcc dot gnu dot org 2010-01-26 07:29 --- fixed in 4.5, 4.3 and 4.4 -- chrbr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #13 from chrbr at gcc dot gnu dot org 2010-01-26 07:28 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:28:05 2010 New Revision: 156231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156231 Log: fix PR target/42841 Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:21:57 2010 New Revision: 156230 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156230 Log: fix PR target/42841 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:20:27 2010 New Revision: 156229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156229 Log: fix PR target/42841 Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #10 from kkojima at gcc dot gnu dot org 2010-01-22 14:28 --- (In reply to comment #9) > So I took the opportunity to cleanup every other > occurrences of the same idioms in the file. OK ? OK. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #9 from christian dot bruel at st dot com 2010-01-22 13:51 --- (In reply to comment #7) > (In reply to comment #6) > > Anyway, OK for trunk ? (just need to fix the date in the ChangeLog). > > regtesting > > done. > > OK. And the patch is pre-approved for branches too after one week or so. > > BTW, I mean JUMP_P(x) && !JUMP_TABLE_DATA_P(x): > didn't read you correctly. So I took the opportunity to cleanup every other occurrences of the same idioms in the file. OK ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #8 from christian dot bruel at st dot com 2010-01-22 13:49 --- Created an attachment (id=19690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19690&action=view) and cleanup with JUMP_TABLE_DATA_P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #7 from kkojima at gcc dot gnu dot org 2010-01-22 13:21 --- (In reply to comment #6) > Anyway, OK for trunk ? (just need to fix the date in the ChangeLog). > regtesting > done. OK. And the patch is pre-approved for branches too after one week or so. BTW, I mean JUMP_P(x) && !JUMP_TABLE_DATA_P(x): a && !(a && (b || c)) == a &&(!a || !(b || c)) == (a && !a) || (a && !(b || c)) == 0 || (a && !(b || c)) == a && !b && !c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #6 from christian dot bruel at st dot com 2010-01-22 12:58 --- (In reply to comment #5) > (In reply to comment #4) > > Conservatively increase length of undelayed conditional branches to prevent > > a > > problem with the ds scheduler inserting an instruction in the slot. > > Looks fine. A very minor nit, JUMP_P and JUMP_TABLE_DATA_P macro > can be used for the first 3 lines of the if-condition. > Thanks. I don't think I can use JUMP_TABLE_DATA_P since this is a != test and JUMP_TABLE_DATA_P includes JUMP_P. Anyway, OK for trunk ? (just need to fix the date in the ChangeLog). regtesting done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-01-22 12:33 --- (In reply to comment #4) > Conservatively increase length of undelayed conditional branches to prevent a > problem with the ds scheduler inserting an instruction in the slot. Looks fine. A very minor nit, JUMP_P and JUMP_TABLE_DATA_P macro can be used for the first 3 lines of the if-condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #4 from christian dot bruel at st dot com 2010-01-22 12:06 --- Created an attachment (id=19689) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19689&action=view) Conservative fix. Conservatively increase length of undelayed conditional branches to prevent a problem with the ds scheduler inserting an instruction in the slot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #3 from christian dot bruel at st dot com 2010-01-22 11:47 --- Hello, I had a similar problem a while ago, but was never able to reproduce on trunk. I was a phasing problem between branch_shortening from sh_reorg and the delayed branch scheduler, that would change the size of a bf (2) against a bf/s+instruction (4). Thus breaking surrounding branch offsets. -fno-delayed-branch is the workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-01-22 08:11 --- I've confirmed that the test case also fails on 4.5.0 and doesn't on 4.2.4. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 GCC build triplet|sh4-linux-gnu | GCC host triplet|sh4-linux-gnu | Keywords||wrong-code Known to fail||4.3.4 4.4.3 4.5.0 Known to work||4.2.4 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-01-22 08:11:31 date|| Summary|Assembler complains pcrel |[4.3/4.4/4.5 Regression] SH: |too far.|Assembler complains pcrel ||too far. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
