https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #10 from Jeffrey A. Law <law at redhat dot com> --- Yes, it's a fairly strict interpretation, but I think it's the right one to be using in the absence of additional language around the semantics of b_c_p. In particular refer to c#6 in BZ38789. Essentially b_c_p or b_o_s is more like a PHI than a function call. All paths to the b_c_p/b_o_s site participate in the result. Thus isolating a path where there's a b_c_p/b_o_s is an invalid transformation unless we prove the original and isolated paths produce the same results for the b_c_p/b_o_s call. But there's no real infrastructure in place to do that. Even something like block duplication for loop header copying or unrolling has the potential to make a b_c_p/b_o_s call give different results between the two paths. So ISTM the only correct thing to do is disable duplication of blocks with those builtins.
