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 <sourceware-bugzi...@sourceware.org> 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils