[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P

[rguenther at suse dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=24464

--- Comment #4 from rguenther at suse dot de ---
On April 18, 2019 3:49:02 PM GMT+02:00, nickc at redhat dot com
<address@hidden> wrote:
>https://sourceware.org/bugzilla/show_bug.cgi?id=24464
>
>--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
>Hi Martin, Hi Richard,
>
>  The assembler is struggling because the BNE instruction could be two
>  different sizes.  It is trying to choose the smallest possible size
>  for the instruction, but at the same time it is trying to honour the
> BALIGN directive and keep the fragment of code starting at .L7 aligned
>  to a two byte boundary.
>
>  In the end it bounces between two different possible values until the
>  loop limit built in to the assembler kicks in.  Interestingly enough
>  the RX backend for the assembler has code to handle this specific
>situation, but this only kicks in after 10 iterations of the relaxation
>  code.  The infinite loop warning built in to the assembler's generic
>code is triggered after 2^N attempts, where N is the number of
>fragments
>  of assembler in the source.  (For the purposes of this PR, fragments
>  can be considered to be pieces of assembler separated by the .balign
>  directive).  If the testcase were bigger, with more fragments in it,
>  then the error message would not appear, because the RX backend's own
>  code would be triggered before the generic code.
>
>  I am uploading a patch which would fix this specific problem, but I
>  do not think that it would be a good idea to apply it.  Overall, it
>  will degrade the assembler's ability to reduce RX code size, for 
>  large binaries, as it reduces the number of relaxation attempts.  Is
>  this PR a real problem for you ?  

It prevents build of a rx-elf cross of GCC 9 during libstdc++ build. So I'd say
yes.

But maybe there's a different solution? IMHO allowing an insn to both shrink a
d grow during an iteration scheme is inherently unstable. If that's necessary
to get optimal results then maybe a set of final iterations with stricter rules
should be applied after hitting the iteration limit? 

If not then I would rather not 
>  apply the patch.
>
>
>(In reply to Richard Biener from comment #1)
>
>> Btw, passing -relax to the assembler makes it assemble OK, producing
>
>  The -relax option is a bit misleading.  What it does is to enable 
>  link-time relaxation of the RX instructions, as opposed to 
>  assembly-time relaxation.  So it has the effect of turning off (some
>  of) the assembler's relaxation code, thus making the size of the two 
>  fragments fixed, and hence preventing the problem.
>
>> likewise writing bne.b instead of bne in the assembly.  That's odd
>> since w/o the .balign and without -relax gas produces the same:
>
>  Specifying a fixed size for the BNE instruction means that it cannot
>  be relaxed, and hence the size of the fragment containing it is now
>  constant, and so again the problem does not arise.
>
>Cheers
>  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.