[llvm-bugs] [Bug 34515] std::indirect_array::operator= gives wrong result.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34515

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |INVALID

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> ---
OK, so first off, what you're *trying* to do probably results in UB.

[indirect.array.assign]p2 says: "If the indirect_array specifies an element in
the valarray<T> object to which it refers more than once, the behavior is
undefined."

It doesn't seem obvious to me what happens if that is true of the source and
destination indirect_arrays, but the same rule would seem reasonable. That
matches what libstdc++ does -- in its implementation, the relevant pointers are
marked as __restrict__, so aliasing would result in UB.


However, what you're *actually* doing is relying on a MSVC and libstdc++ bug.
Here's how indirect_array's assignment operator is *supposed* to be declared:

  const indirect_array& operator=(const indirect_array&) const;

That's what libc++ does. Despite the UB I mentioned above, that assignment
(probably) results in UB, but in practice assigns left-to-right, thus assigning
input[1] (== 1) to input[1], then assigning input[2] (== 2) to input[3], then
assigning input[3] (now == 2) to input[4], then assigning input[4] (now == 2)
to input[6]. And the answer is {1, 2, 2, 2}.


The MSVC / libstdc++ bug is that they declare the assignment operator as

  const indirect_array& operator=(const indirect_array&);

(Note the lack of 'const'.) Your code does not call that function. Instead, it
calls

  const indirect_array& operator=(const valarray&) const;

... after converting result2 to a valarray<int> (which reads all the elements
at once).


So your code probably has UB, and in any case it's the other two
implementations that are wrong :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170907/2379ce8c/attachment.html>