------- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-27 14:35 ------- Weird. A trigger for the failure with -flto is the removal of a dead store in container_rand_regression_test<Cntnr>::assignment_operator(). We remove
tmp.D.3238.D.3239.D.3240.D.3090.D.3046.D.3014._vptr.hash_load_check_resize_trigger = &_ZTVN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEEEE[2]; at the beginning of BB 21. If you retain that store then this will be the only assembly code difference and the segfault disappears. Reduced flags: -O2 -fno-tree-pre -fno-ivopts -fno-tree-loop-optimize -fno-dse -fno-gcse -fno-tree-sink -fno-tree-dominator-opts -fno-tree-vrp -fno-tree-fre either specifying -fno-strict-aliasing or -fno-tree-dse also fixes the segfault. The funny thing is that trunk (or the branch w/o -flto) also removes that store. I'll attach a slightly reduced testcase momentarily (it just reduces the amount of instantiations, not the amount of source). The testcase is rather awkward in that it relies on randomness to perform the operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
