https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
For example, in create():
<bb 4> [local count: 1073741824]:
_15 = MEM[(struct VideoFrame &)&videoFrame].lineSize;
_16 = (long unsigned int) _15;
_17 = MEM[(struct vector *)&videoFrame + 8B].D.4741._M_impl._M_finish;
__trans_tmp_4_19 = _17 - __pos_13;
_20 = (long unsigned int) __trans_tmp_4_19;
if (_16 > _20)
goto <bb 5>; [100.00%]
else
goto <bb 10>; [0.00%]
In dom2, lineSize is read uninitialized. As a bonus create() has no return.
So BB10 has a __builtin_unreachable, which makes DOM2 set _16 to nonzero. This
is set globally, which then causes one of the threaders to thread paths through
BB4, then DOM3 to simplify things further, with the ranger setting some ranges
to UNDEFINED... This cannot end well ;-).
So yeah...we need valid IL.
That being said, the compiler should never ICE. So if the original testcase
has undefined behavior and that's the reason for the ICE, we should fix that as
well.
