These two tests in many places looks for a pattern:
br ... label %<label name> ...
In non-release builds of the compiler, this works fine. For example:
br label %omp.inner.for.cond, !dbg !313
omp.inner.for.cond: ; preds = %omp.inner.for.inc, %cond.end
In a release build, the compiler generates the following:
br label %13, !dbg !313
; <label>:13: ; preds = %20, %11
The filecheck pattern that caused the problem was this:
CHECK: br label %[[SIMD_LOOP7_COND:[^,]+]]
// CHECK-NEXT: [[IV7:%.+]] = load i64, i64* [[OMP_IV7]]
The problem is that in a release build example from above, SIMD_LOOP7_COND gets the value "13", and then the next CHECK line matches the "13" that is part of the same line rather than the intended line 2 lines later. After that, the CHECK-NEXT line fails to match because the next line is blank, rather than the line immediately following the label as the author originally intended.
The fix is to make the label check more explicit by looking for the trailing colon after the label so that it is less likely to match the wrong thing.