This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Am 06.02.2018 um 19:18 schrieb Jonathan Wakely:
> On 6 February 2018 at 18:03, Rainer Emrich wrote:
>
>> At least 20 of the acats tests catch all memory until the host memory is exhausted.
>> Same holds for the two libstdc++ tests
>> 23_containers/unordered_set/requirements/exception/basic.cc
>> and
>> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
>
> Are these new failures? What changed? Where does it get stuck?
>
Some of my observations, I don't know whats expected:
In the function populate p(container_control)
"make_container_n<container_type> made(n);" is called with n=82.
This allocates nearly 16GByte on memory. Is this expected?
Before the call to run_steps_to_limit(container_control, f) the
container_control structure has:
_M_bucket_count = 2019773507
_M_element_count = 82
_M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
_M_next_resize = 2019773507}
To answer my own question, that's not expected. So at this state it's
already wrong.
Attachment:
signature.asc
Description: OpenPGP digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |