https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103254
--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- This is a long sequence, made from the following pattern: _156 = _155 & _147; _157 = (int) _156; j_158 = _157 & j_149; _164 = (short int) j_158; _165 = _164 & _156; Since GORI doesn't yet cache anything, each name evaluation is a "new" request. to resolve _165 it calculates _164 and _156. Note that _164 is also ultimately defined by _156 (in combination with _j_149). so that means we evaluate _156 twice to get _165. This rapidly triggers the same exponential growth we encountered with PR 100081, so we will need to limit this sort of thing in general until GORI starts caching outgoing values.
