https://sourceware.org/bugzilla/show_bug.cgi?id=24464
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Nick Clifton <nickc at redhat dot com> ---
Hi Guys,
>> 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.
>
> It prevents build of a rx-elf cross of GCC 9 during libstdc++ build. So I'd
> say yes.
Right. jeff Law just alerted me to this fact. For future readers the
gcc PR filed for this problem is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
> But maybe there's a different solution? IMHO allowing an insn to both shrink
> and grow during an iteration scheme is inherently unstable.
True - but also inevitable. With variable sized instructions, and multiple,
differently sized versions of the same instruction there is always going to
be this problem.
> 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?
Actually I have thought of a slightly different way to solve the problem.
The bug only happens when the iteration limit in the generic assembler is
smaller than the iteration limit in the RX backend, and this only happens when
a small amount of code is being assembled. So I have patched the backend to
check its iteration limit against the generic limit, and reduce it if
necessary. That way, only small pieces of assembler are affected, and such
small pieces of code really ought to be relaxable with only a few iterations.
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
