https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72712
--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> --- I can also confirm that one can use -fno-expensive-optimizations as a workaround. To provide some obvious analysis: The first "thread" pass increases the number of basic blocks in the function from 9183 to 25392, the second one from 23973 to 37789, then they get eliminated somehow so the third one begins with 27599 but again finishes with 38018, which the fourth then tops to 45291 basic blocks (and then my ulimit killed the compiler).
