[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

[rguenth at gcc dot gnu dot org]

------- 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