aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2020-06-17 20:53:45 +0100
committerJonathan Wakely <jwakely@redhat.com>2020-06-17 20:55:06 +0100
commitc9dce3b15e89e851f59ebe9e8879c8f3a620311a (patch)
tree38e621db673a7f18290550caec087ca04ba20052 /gcc
parentd392babbeb6cb531ab8b1ec68fde9ffd36373a6e (diff)
downloadgcc-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