aboutsummaryrefslogtreecommitdiff
path: root/gcc/ada/gcc-interface/utils.c
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2020-09-10 15:39:15 +0100
committerJonathan Wakely <jwakely@redhat.com>2020-09-10 15:42:09 +0100
commit30b41cfbb2dade63e52465234a725d1d02fe70aa (patch)
tree4f573dfe983bb67429b910e2f42f099496bb2e25 /gcc/ada/gcc-interface/utils.c
parent1e718ec51a223d65a09757b999202390871b778d (diff)
downloadgcc-30b41cfbb2dade63e52465234a725d1d02fe70aa.zip
gcc-30b41cfbb2dade63e52465234a725d1d02fe70aa.tar.gz
gcc-30b41cfbb2dade63e52465234a725d1d02fe70aa.tar.bz2
libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160]
When a pool resource is constructed with max_blocks_per_chunk=1 it ends up creating a pool with blocks_per_chunk=0 which means it never allocates anything. Instead it returns null pointers, which should be impossible. To avoid this problem, round the max_blocks_per_chunk value to a multiple of four, so it's never smaller than four. libstdc++-v3/ChangeLog: PR libstdc++/94160 * src/c++17/memory_resource.cc (munge_options): Round max_blocks_per_chunk to a multiple of four. (__pool_resource::_M_alloc_pools()): Simplify slightly. * testsuite/20_util/unsynchronized_pool_resource/allocate.cc: Check that valid pointers are returned when small values are used for max_blocks_per_chunk.
Diffstat (limited to 'gcc/ada/gcc-interface/utils.c')
0 files changed, 0 insertions, 0 deletions