thurstond wrote: > Cost is one alloca + one store per write + one load/branch per read, for > candidate scalars only. Given -fsanitize=undefined is supposed to stay cheap, > wanted to check before implementing: fine as part of the Undefined group, or > would you rather this sit behind its own flag?
The allocas would make this check unusual by UBSan standards, let alone `-fsanitize=undefined`: "UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector. ... The checks have small runtime cost and no impact on address space layout" (https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) ---- The current implementation of this check is targeted towards ISO C23 6.3.2.1p2, which is not obvious from the check name (`-fsanitize=uninitialized-check`), and would potentially confuse users of other C or C++ dialects why the check doesn't work as expected. It would be better if the check implemented the semantics for the appropriate dialect per the `CGF.getLangOpts()`. Users may also be confused by the difference between `-fsanitize=uninitialized-check` and `-fsanitize=memory` (arguably the former is a better description of what MemorySanitizer actually does). Instead of an extra UBSan check, is it possible for the front-end to instead add appropriate annotations/attributes to make MemorySanitizer work correctly for this C23? https://github.com/llvm/llvm-project/pull/207529 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
