I found this bug while working on JDK-8375442, several unit tests are failing when deep revisit from JDK-8375442 is enabled in all IGVN rounds (all igvn->optimize() calls).

When is_clonebasic() ArrayCopyNodes are macro-expanded via BarrierSetC2::clone_at_expansion, the pre-existing trailing MemBar is not flagged with trailing_expanded_array_copy.

The other expansion path (generate_arraycopy) creates a new MemBar and sets the flag, but the clone path simply replaces the ArrayCopyNode with a CallLeafNoFP and does not flag the MemBar.

After expansion, ArrayCopyNode::may_modify(t_oop, MemBarNode*, phase, ac) can no longer find the ArrayCopyNode through the MemBar's control chain. Without the flag, it returns false, causing optimize_simple_memory_chain to walk past the MemBar to the Initialize node's zero-filled memory. Loads from the cloned object are then incorrectly replaced with zero.

This is latent under normal IGVN because loads are finalized before macro expansion, when may_modify can still find the ArrayCopyNode. JDK-8375442 re-pushes loads (among others) onto the IGVN worklist after macro expansion has already replaced the ArrayCopyNode, exposing the issue.

---
sample failure:

works with ReduceBulkZeroing enabled and disabled (as in the test).

build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:-ReduceBulkZeroing '-XX:CompileCommand=dontinline,compiler.arraycopy.TestCloneAccess::*' test/hotspot/jtreg/compiler/arraycopy/TestCloneAccess.java
CompileCommand: dontinline compiler/arraycopy/TestCloneAccess.* bool dontinline = true
Exception in thread "main" java.lang.RuntimeException: Wrong result! Expected: res = 7, e.i1 = 3, e.i2 = 4 but got: res = 0, e.i1 = 3, e.i2 = 4
        at compiler.arraycopy.TestCloneAccess.main(TestCloneAccess.java:62)