diff options
author | Jonathan Wakely <jwakely@redhat.com> | 2020-06-17 20:53:45 +0100 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2020-06-17 20:55:06 +0100 |
commit | c9dce3b15e89e851f59ebe9e8879c8f3a620311a (patch) | |
tree | 38e621db673a7f18290550caec087ca04ba20052 /gcc | |
parent | d392babbeb6cb531ab8b1ec68fde9ffd36373a6e (diff) | |
download | gcc-c9dce3b15e89e851f59ebe9e8879c8f3a620311a.zip gcc-c9dce3b15e89e851f59ebe9e8879c8f3a620311a.tar.gz gcc-c9dce3b15e89e851f59ebe9e8879c8f3a620311a.tar.bz2 |
libstdc++: Handle non-integral sizes in std::uninitialized_fill_n
The std::uninitialized_fill_n algorithm uses sd::fill_n for trivial
types, but that algorithm has a stronger requirement that the Size
parameter is convertible to an integral type. As the new test shows,
there are types which are valid for std::uninitialized_fill_n but which
produce a different result when converted to an integral type, or cannot
be converted at all. Only use the std::fill_n optimization when the Size
type is already an integral type.
The std::__uninitialized_default_n extension has the same problem, and
so does C++17's std::uninitialized_value_construct_n which uses it.
* include/bits/stl_uninitialized.h (uninitialized_fill_n): Only
use std::fill_n when the size is an integral type.
(__uninitialized_default_n): Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/sizes.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc:
New test.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions