bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attemp


From: nickc at redhat dot com
Subject: [Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
Date: Fri, 19 Apr 2019 09:43:50 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]