https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122686
--- Comment #26 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #25) > Created attachment 62894 [details] > LTO IR testcase > > With the attached "testcase" you can reproduce the hang (and debug it) on > trunk around r16-5548-gb207d9d1836ea1 (at some point the LTO IL will become > invalid). > To reproduce: > > ./lto1 -quiet -dumpbase ./wrf_r.ltrans113.ltrans -march=x86-64-v3 -g0 -Ofast > -Ofast -version -fno-openacc -fno-pie -fcf-protection=none -fno-openmp > -fltrans ./wrf_r.ltrans113.o -o ./wrf_r.ltrans113.ltrans.s > > and observe that ranger_cache::propagate_cache does not finish. ah yes, that helps. I can reproduce it. Looks like another bitmask related thing with a range flip-flopping between two different masks. : [irange] sizetype [12, 12][20, 20][28, 28] MASK 0x18 VALUE 0x4 [irange] sizetype [12, 12][20, 20][28, 28] MASK 0x1c VALUE 0x0 We should be able to settle on the more restrictive mask.. leave it with me. Thanks
