[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-09-01 12:21 --- Let's reopen it as LTO specific. The test still fails on i?86 with the original multi-file testcase and -flto. There are also other similar pb_ds fails. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Component|c++ |lto Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-08-28 09:57
---
Instantiating
_ZN10__gnu_pbds13gp_hash_tableINS_4test10basic_typeES2_NS1_4hashESt8equal_toIS2_ENS1_27direct_mod_range_hashing_t_IN9__gnu_cxx15throw_allocatorIS2_NS1_21quadratic_probe_fn_t_IS2_S9_EENS_27hash_standard_resize_policyINS1_25hash_prime_size_policy_t_ENS1_33hash_load_check_resize_trigger_t_IS9_Lj1ELj8ELj1ELj2ELb1EEELb1EjEELb0ES9_EaSERKSI_
tmpD.97537.D.92388.D.92047.D.91561.D.91103.D.89988.D.89882._vptr.hash_load_check_resize_triggerD.89847
other.1162D.116069_22 = (struct equal_toD.83779 *)
&tmpD.97537.D.92388.D.92047.D.91561;
*this.1163D.116068_23 = *other.1162D.116069_22;
Dissecting the types of
tmpD.97537.D.92388.D.92047.D.91561.D.91103.D.89988.D.89882._vptr.hash_load_check_resize_triggerD.89847:
bit offset
offset bit offset
bit offset
bit offset
record_type 0xbe00 hash_standard_resize_policy
fields bit offset
bit offset
offset bit offset
Shows that
other.1162D.116069_22 = (struct equal_toD.83779 *)
&tmpD.97537.D.92388.D.92047.D.91561;
takes the address of gp_ht_map_data_. There is no equal_to typed field in
this struct.
So the question boils down to who is responsible for the std::swap of this
"field" and how do we end up with this code.
It seems to be
_ZN10__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_Lj1ELj8ELj1ELj2ELb1EEELb1EjEEE4swapERSJ_
calling
other.1158D.107162 = (const struct hash_eq_fnD.89704 *) otherD.90715;
this.1159D.107163 = (struct hash_eq_fnD.89704 *) thisD.90714;
_ZN10__gnu_pbds6detail10hash_eq_fnINS_4test10basic_typeESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0EE4swapERKS9_D.89731
(this.1159D.107163, other.1158D.107162);
;; Function swap
(_ZN10__gnu_pbds6detail10hash_eq_fnINS_4test10basic_typeESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0EE4swapERKS9_)
swap (struct hash_eq_fnD.89704 * const thisD.89732, const struct
hash_eq_fnD.89704 & otherD.89733)
{
struct equal_toD.83779 * this.1163D.107177;
struct equal_toD.83779 * other.1162D.107176;
:
other.1162D.107176 = (struct equal_toD.83779 *) otherD.89733;
this.1163D.107177 = (struct equal_toD.83779 *) thisD.89732;
_ZSt4swapISt8equal_toIN10__gnu_pbds4test10basic_typeEEEvRT_S6_D.99289
(this.1163D.107177, other.1162D.107176);
return;
}
ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp:
PB_DS_CLASS_T_DEC
void
PB_DS_CLASS_C_DEC::
swap(PB_DS_CLASS_C_DEC& other)
{
_GLIBCXX_DEBUG_ONLY(assert_valid());
_GLIBCXX_DEBUG_ONLY(other.assert_valid());
std::swap(m_num_e, other.m_num_e);
std::swap(m_num_used_e, other.m_num_used_e);
std::swap(m_entries, other.m_entries);
ranged_probe_fn_base::swap(other);
hash_eq_fn_base::swap(other);
resize_base::swap(other);
_GLIBCXX_DEBUG_ONLY(debug_base::swap(other));
_GLIBCXX_DEBUG_ONLY(assert_valid());
_GLIBCXX_DEBUG_ONLY(other.assert_valid());
}
where hash_eq_fn_base::swap(other); is the culprit.
ext/pb_ds/detail/eq_fn/hash_eq_fn.hpp:
PB_DS_CLASS_T_DEC
inline void
PB_DS_CLASS_C_DEC::
swap(const PB_DS_CLASS_C_DEC& other)
{ std::swap((Eq_Fn& )(*this), (Eq_Fn& )other); }
WTF?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-27 16:08 --- Thanks paolo. It is btw _ZN10__gnu_pbds13gp_hash_tableINS_4test10basic_typeES2_NS1_4hashESt8equal_toIS2_ENS1_27direct_mod_range_hashing_t_IN9__gnu_cxx15throw_allocatorIS2_NS1_21quadratic_probe_fn_t_IS2_S9_EENS_27hash_standard_resize_policyINS1_25hash_prime_size_policy_t_ENS1_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEELb0ES9_E4swapERSI_ that has this issue. That is, basic_hash_table<...>::swap which eventually ends up - somewhere (it's a maze in that libstdc++!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #10 from paolo dot carlini at oracle dot com 2009-08-27 16:00 --- Richard, I have no idea, at the moment. Frankly however, I know, or at least strongly suspect basing on past and still open issues, that pb_ds cannot be fully trusted, isn't really maintained as it should and unfortunately the original author isn't available anymore. Sorry, but I don't think I'm going to spend much time on this issue or anything having to do with this ext/ code, for that matter. I'm CC-ing Benjamin - for sure he knows the code much better than me - just for his information. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo dot carlini at oracle |bkoz at redhat dot com |dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-27 15:43 ---
In fact the code generated by the C++ frontend (or the library) looks bogus.
other.1157_15 = (const struct hash_eq_fn *) D.107435_2;
this.1158_16 = (struct hash_eq_fn *) D.107436_4;
other.1161_17 = (struct equal_to *) other.1157_15;
this.1162_18 = (struct equal_to *) this.1158_16;
__tmp = *this.1162_18;
*this.1162_18 = *other.1161_17;
*other.1161_17 = __tmp;
this swaps the first byte(!) of the struct which contains the vtable pointer.
In fact gp_hash_table::swap(gp_hash_table&) seems to cause this. Forcing
to not inline that function fixes the issue as well.
(so the dead store really is not dead - but only because of that bogus swap).
Thus, things like
void
_M_swap(_Hash_code_base& __x)
{
std::swap(_M_extract, __x._M_extract);
std::swap(_M_eq, __x._M_eq);
std::swap(_M_h1, __x._M_h1);
std::swap(_M_h2, __x._M_h2);
}
protected:
_ExtractKey _M_extract;
_Equal _M_eq;
_H1 _M_h1;
_H2 _M_h2;
};
seem to corrupt the vtable pointer as the empty function classes are
tail-packed into that field. OTOH std::swap should do nothing for
empty classes, but instead it does
;; Function void std::swap(_Tp&, _Tp&) [with _Tp =
std::equal_to<__gnu_pbds::test::basic_type>] (null)
;; enabled by -tree-original
{
struct equal_to __tmp;
struct equal_to __tmp;
<) >>>
>>;
<>>
>>;
<>>
>>;
}
bah. Paolo, who is at fault here? The library or the frontend? The
issue must be latent on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||paolo dot carlini at oracle
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-27 14:36 --- Created an attachment (id=18437) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18437&action=view) testcase, simplified -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- 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::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_Lm1ELm8ELm1ELm2ELb1EEELb1Em[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
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-26 08:23 --- Created an attachment (id=18426) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18426&action=view) single-file testcase It reduced to nonsense again. *sigh* Attaching the single-file input for reference. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #18355|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #5 from ubizjak at gmail dot com 2009-08-26 06:27 --- FYI, this testcase also fails on alpha: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test (I was not able to debug it properly, will wait for your reduced testcase...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-19 11:15 --- I'm reducing again, from a single-file testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: hash_data_map_rand|FAIL: ||ext/pb_ds/regression/hash_da ||ta_map_rand.cc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
