https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the bug is introduced during forwprop3:
--- pdftex-pdftex-pool.i.125t.dce3 2018-02-20 14:09:25.561460216 +0100
+++ pdftex-pdftex-pool.i.126t.forwprop3 2018-02-20 14:09:25.561460216 +0100
@@ -40,12 +40,12 @@ loadpoolstrings (long int spare_size)
# j_45 = PHI <1(2), j_18(6)>
# PT = nonlocal escaped null
# s_46 = PHI <"mu"(2), s_19(6)>
- # RANGE [0, 2147483645] NONZERO 2147483647
+ # RANGE [2, 4294967295] NONZERO 2147483647
# USE = nonlocal escaped
_1 = __builtin_strlen (s_46);
# RANGE [0, 2147483645] NONZERO 2147483647
l_20 = (int) _1;
- i_21 = i_40 + l_20;
+ i_21 = l_20 + i_40;
if (i_21 >= spare_size_22(D))
goto <bb 7>; [5.50%]
else
While s_46 is "mu" in the first iteration and thus it has length of 2, the
length of second and following strlen calls are in this case all 0.
In the original pdftex-pool.c the first string is ".6", then many non-empty
strings with various length, then this "mu" string, then "" on which it hangs
because of the incorrect range we assume the while (l-- > 0) strpool[poolptr++]
= *s++; loop iterates at least once and we don't need to check for l > 0 before
the loop, and then lots of other strings.
