https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123248
--- Comment #2 from Yuxiao Peng <220246428 at seu dot edu.cn> --- (In reply to Andrew Pinski from comment #1) > Iirc this is by design. In this case the store is dead so it does not hurt. Thanks for the clarification, Andrew. I understand that from a pure data-flow perspective, the store is dead and its removal is a standard optimization. However, from a diagnostic standpoint, this creates a "silent safety gap." When a user explicitly passes -fsanitize=address, the intent is to audit the memory safety of the source logic, not just the final observable output. In this case, the source logic contains a clear UAF. While the store is "dead" to the optimizer, it is "active" as a bug. If -O1 silently removes the only manifestation of a bug, the developer receives a false Pass, whereas -O0 would have caught it. Would it be possible to consider an option (or a change in heuristic) where -fsanitize=address makes the compiler more conservative about deleting potentially invalid memory accesses? Or at least, should this "optimization-driven diagnostic loss" be documented as a known limitation for users relying on ASan at -O1+?
