summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/LoopVectorize/conditional-assignment.ll
diff options
context:
space:
mode:
authorMehdi Amini <mehdi.amini@apple.com>2016-10-06 23:26:29 +0000
committerMehdi Amini <mehdi.amini@apple.com>2016-10-06 23:26:29 +0000
commita7e893f6387384def77c804da7e51d02c0b8bf50 (patch)
tree74731175147112c1a8df42dc5984ec579cce47b0 /llvm/test/Transforms/LoopVectorize/conditional-assignment.ll
parente15a370084f376be480072c06ebd94bbeac6663c (diff)
downloadbcm5719-llvm-a7e893f6387384def77c804da7e51d02c0b8bf50.tar.gz
bcm5719-llvm-a7e893f6387384def77c804da7e51d02c0b8bf50.zip
Add a static_assert to enforce that parameters to llvm::format() are not totally unsafe
Summary: I had for the second time today a bug where llvm::format("%s", Str) was called with Str being a StringRef. The Linux and MacOS bots were fine, but windows having different calling convention, it printed garbage. Instead we can catch this at compile-time: it is never expected to call a C vararg printf-like function with non scalar type I believe. Reviewers: bogner, Bigcheese, dexonsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25266 llvm-svn: 283509
Diffstat (limited to 'llvm/test/Transforms/LoopVectorize/conditional-assignment.ll')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud