bgra8 wrote: You are right — in a normal call, not zero-extending sub-64-bit aggregate parameters is not an issue for MSan as long as the callee does not access the upper bytes.
After digging further, we found that this PR only exposed a pre-existing bug in Clang's `CodeGenFunction::GenerateCode` that can also trigger without this change (on both AArch64 and x86_64): 1. When Clang emits a `.inline` clone for a redefined `always_inline` `gnu_inline` C library builtin (such as glibc's fortified `memcpy` or `vsnprintf` wrappers under `-D_FORTIFY_SOURCE=2`), `CodeGenFunction::GenerateCode` creates the cloned `llvm::Function` and calls `replaceAllUsesWith`, but does not copy the original function's target attributes (`target-cpu`, `target-features`, `tune-cpu`) or parameter attributes (`noundef`) onto the clone. 2. Because the `.inline` clone is missing target attributes, target inline-compatibility checks (for example, when `-mcpu` and `-mtune` differ on AArch64, or under function-level `target(...)` attributes on x86_64) can prevent the `.inline` clone from being inlined despite `always_inline`. 3. When the `.inline` clone is emitted out-of-line, the call site retains `noundef` on its arguments (from the original declaration), while the cloned function definition lacks `noundef` on its parameters. Under MSan's `-msan-eager-checks`, this mismatch causes the caller to skip writing `@__msan_param_tls` before the call while the `.inline` callee's prologue still reads `@__msan_param_tls`, trapping on any non-zero shadow bytes left in `@__msan_param_tls` by a preceding call (such as an empty C++ struct argument after this PR, or any struct with internal padding even without this PR). So your change is probably fine as-is, and we should focus on fixing `.inline` builtin clone attribute propagation in Clang. https://github.com/llvm/llvm-project/pull/215264 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
