<algorithm>: Fix conditions for vectorization on trivial assignability by frederick-vs-ja · Pull Request #5528 · microsoft/STL (original) (raw)

It's shown in WG21-P3279R0 that is_trivially_(copy_,move_)assignable is sometimes not it self a suitable condition for vectorization, because a derived class can be "trivially-assigned" via a trivial assignment operator of its base class.

This PR strengthens the conditions by checking the return type of the assignment. I.e. the corresponding conditions are now that

• T is trivially assignable from the source, and
• the assignment returns T&, which means that when T is a class, a defaulted and trivial T::operator= is selected, and
• other conditions.

Pedantically, a defaulted and trivial T::operator= possibly skips a subobject due to aforementioned weird derived classes. But currently, all mainstream compilers don't think so (see LLVM-37038, "reject-valid" demo, and "accept-invalid" demo). So I think the condition is safe despite not being theoretically sufficient.

Also, (ranges::)reverse_copy should rely on trivial assignability, and we shouldn't vectorize it for element type pair<T&, U&> just because trivially copyability. Actually, being trivially copyable doesn't mean any expected operation is publicly available and trivial.

Affected algorithms:

• (ranges::)copy,
• (ranges::)copy_n,
• (ranges::)copy_backward,
• (ranges::)move,
• (ranges::)move_backward,
• (ranges::)reverse_copy.

Fixes #4686.