efriedma added a comment. gcc apparently lowers this sort of construct to a volatile load/store followed by a trap. Not sure where the trap is coming from.
I'm not sure this solves any problem that really needs to be solved. LLVM isn't going to optimize out a volatile load/store to null. Well, unless you have a volatile load followed by __builtin_unreachable() or equivalent, but that applies to any volatile load. I'd rather not make assumptions about what the user is trying to do, or change the behavior of the user's code if they use -fno-delete-null-pointer-checks, or change the behavior of user code depending on how they write nullptr. On a related note, it might be worth considering turning on TrapUnreachable/NoTrapAfterNoreturn by default in the backend; it's probably cheap in terms of codesize, and it might reduce user confusion around unreachable branches. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105728/new/ https://reviews.llvm.org/D105728 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
