[Bug libstdc++/63314] New: valarray mask/indices refers to temporary

[Bug libstdc++/63314] New: valarray mask/indices refers to temporary

[helloworld922 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63314

            Bug ID: 63314
           Summary: valarray mask/indices refers to temporary
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: helloworld922 at hotmail dot com

std::mask_array appears to be holding a reference to the underlying _M_data of
the mask std::valarray. This is a problem when the mask valarray is a
temporary:

std::valarray<int> data = {1,4,0,2,5};
std::mask_array<int> marr = data[data <= 2];

Here, the data <= 2 mask is a temporary and sarr will have an invalid address
for for the mask _M_data. Trying to do anything with mask_array at this point
would have problems, i.e.:

marr = 11;

will be undefined behavior.

Similarly, there is an identical issue with std::indirect_array:

std::indirect_array<int> iarr = data[std::valarray<size_t>({1,2,4})];

Because the underlying _M_data has no ownership in mask_array/indirect_array,
there are additional problems when trying to return the given type:

std::mask_array<int> doit(const std::valarray<int> &data)
{
    std::valarray<size_t> idx = {1,2,3};
    return data[idx];
}

It is unclear to me if this behavior is allowed by the standard, but it
certainly looks fishy, especially given that the deduced type for this:

auto marr = data[data <= 2];

is std::mask_array

[Bug libstdc++/63314] valarray mask/indices refers to temporary

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63314

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to helloworld922 from comment #0)
> It is unclear to me if this behavior is allowed by the standard, but it
> certainly looks fishy

In that case you really shouldn't claim the bug's severity is "blocker"