On 30 January 2018 at 09:28, Sameera Deshpande <sameera.deshpa...@linaro.org> wrote: > On 30-Jan-2018 2:37 AM, "Richard Sandiford" <richard.sandif...@linaro.org> > wrote: > > Sameera Deshpande <sameera.deshpa...@linaro.org> writes: >> Hi! >> >> I am seeing multiple assembler errors with error message "Error: >> conditional branch out of range" for customer code. >> >> The root cause of the bug is that conditional branches are generated >> whose branch target ends up being too far away to be encoded in the >> instruction. It appears that there was an attempt to fix this issue >> in the below change: >> >> commit 050af05b9761f1979f11c151519e7244d5becd7c >> Author: thopre01 <thopre01@138bc75d-0d04-0410-961f-82ee72b054a4> >> Date: Thu Aug 27 10:08:54 2015 +0000 >> >> 2015-08-27 Ramana Radhakrishnan >> <[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]> >> Andre Vieira >> <[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]> >> >> gcc/ >> * config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump): >> Handle functions > 1 MiB. >> (*cb<optab><mode>1): Likewise. >> (*tb<optab><mode>1): Likewise. >> (*cb<optab><mode>1): Likewise. >> * config/aarch64/[iterators.md|http://iterators.md/] (inv_cb): >> New code attribute. >> (inv_tb): Likewise. >> * config/aarch64/aarch64.c (aarch64_gen_far_branch): New. >> * config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New. >> >> gcc/testsuite/ >> * gcc.target/aarch64/long_branch_1.c: New test. >> >> However, as per GCC Internal documentation, only special attribute >> "length" should use PC and match_dup while defining an attribute. I >> verified by looking at code in final pass, and realised that >> get_attribute_length does not map directly to the functions generated >> from the definition of attribute length in RTL patterns, but computes >> the lengths in shorten_branches and uses insn_current_length as >> intermediate function. >> >> The far_branch attribute defined similar to attribute length expects >> same values to be returned by (minus (match_dup 2) (pc)) which is >> incorrect. >> >> I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few >> other architectures, to emit far branches. >> >> Is that approach acceptable? > > I don't think we need to go that far. The INSN_ADDRESSES should be > correct when outputting the instructions, so does it work if we use > those instead of get_attr_far_branch? > > Thanks, > Richard > >> PS: I am waiting for customer's approval for attaching the test case. > > > Hi Richard, > > Thanks for your reply. I will try using INSN_ADDRESSES and will get back to > you. > > - Thanks and regards, > Sameera D. >
Hi Richard, I verified that it works. Thanks a lot! Will do the testing, and update the patch. -- - Thanks and regards, Sameera D.
