[PATCH] D127812: [AArch64] FMV support and necessary target features dependencies.

[Mitch Phillips via Phabricator via llvm-commits]

hctim added a comment.

In D127812#4012276 <https://reviews.llvm.org/D127812#4012276>, @ilinpv wrote:

> I've managed to reproduce "MemorySanitizer: use-of-uninitialized-value" error locally, thank you @hctim for help!
> If I understand it right, it seems **MSan didn't handle correctly SmallVector** - a variable-sized array with some number of elements in-place and heap allocation for additional elements if needed:
>
>   clang/lib/Sema/SemaDeclAttr.cpp:3615 SmallVector<SmallString<64>, 2> StringsBuffer;
>
> There were 2 elements in-placed for StringsBuffer and tests which require 3 failed with MSan use-of-uninitialized-value error. 
> With number of StringsBuffer in-placed elements set to 3
>
>   SmallVector<SmallString<64>, 3> StringsBuffer;
>
> all use-of-uninitialized-value errors have gone.

I'm not sure "MSan didn't handle correctly SmallVector" is the case. Given your diagnosis of 3-elements-vs-2, I'm guessing the root cause is that `clang/lib/Sema/SemaDecl.cpp:11369` is wrong:

  !std::equal(CurClones->featuresStrs_begin(),
              CurClones->featuresStrs_end(),
              NewClones->featuresStrs_begin()))) {

This construction of `std::equal` is very error-prone, as if `NewClones.size() < CurClones.size()`, then this invariable leads to buffer-overflow. I'm wondering if that's the underlying cause, it would seem entirely possible that expanding the in-place elements are always "initialized" from MSan's perspective and so the current code has a false-negative, and your new code made it so that the vector is now heap-based, which is revealing the underlying issue. Maybe worth trying one more thing and adding an `assert(CurClones->size() <= NewClones->size());` to double check?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127812/new/

https://reviews.llvm.org/D127812