https://github.com/jrtc27 approved this pull request.
This should be low risk. If the condition holds, it would previously dereference an invalid iterator, and either crash immediately thanks to assertions or use whatever junk's in memory. Now it will treat it the same as if there's an immediate terminator, i.e. has no non-terminator instructions. So it's turning definitely wrong, likely crashing, behaviour into something that's believed correct, and is not affecting anything other than the case where the iterator was invalid. The only risk I can personally see is if the new behaviour is incorrect, then you've gone from likely crashing to definitely miscompiling, but this seems unlikely given the intent of the surrounding code, and would only affect Windows SEH data in this corner case. The other argument against it would be that it's been broken since the release of LLVM 17 rather than being a regression in LLVM 19, though of course whether you hit it or not for real-world code is going to be dependent on the exact optimisations performed, and it could well be those prior versions didn't (I don't know/recall if the reporter tried compiling the original code in question with 17 or 18). https://github.com/llvm/llvm-project/pull/107466 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
