--- 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:
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-08-28 09:57
---
Instantiating
--- 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_testCntnr::assignment_operator(). We remove
--- 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=18437action=view)
testcase, simplified
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
--- 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
--- 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
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-27 16:08
---
Thanks paolo.
It is btw
--- 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...)
--
--- 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
