--- Comment #29 from ubizjak at gmail dot com 2009-09-01 12:00 ---
(In reply to comment #28)
> This may be related to PR 37144.
No, it was assembler bug with 2.19.1 in my case.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #28 from hjl dot tools at gmail dot com 2009-08-31 23:09
---
This may be related to PR 37144.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
--- Comment #27 from ubizjak at gmail dot com 2009-08-31 19:01 ---
(In reply to comment #26)
> The line that will fail to link to correct LSDA is marked with >>>.
This issue is reported in binutils bugzilla as Bug 10579 [1].
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10579
-
--- Comment #26 from ubizjak at gmail dot com 2009-08-31 18:44 ---
Created an attachment (id=18456)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18456&action=view)
alpha dump
This is the dump. Please look for $LSFDE285:
$LSFDE285:
.4byte $LEFDE285-$LASFDE285
$LASFDE285:
--- Comment #25 from ubizjak at gmail dot com 2009-08-31 18:23 ---
(In reply to comment #24)
> If you think it is a linker bug, try to see if the LSDA pointer in readelf -wf
> dump is correct when you link with --traditional-format. And, file a binutils
No, with --traditional-format, i
--- Comment #24 from jakub at gcc dot gnu dot org 2009-08-31 17:17 ---
If you think it is a linker bug, try to see if the LSDA pointer in readelf -wf
dump is correct when you link with --traditional-format. And, file a binutils
bugreport and attach everything needed to reproduce it ther
--- Comment #23 from ubizjak at gmail dot com 2009-08-31 17:11 ---
Perhaps Jakub can help from here...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #22 from ubizjak at gmail dot com 2009-08-31 16:56 ---
Digging deeper, it smells like a linker error, at least on alpha (please note
that I used -static for final linking to ease debugging a bit):
FDE that corresponds to
_ZN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basi
--- Comment #21 from ubizjak at gmail dot com 2009-08-31 06:52 ---
(In reply to comment #20)
> > Sigh, the patch doesn't fix alpha failure :(
>
> It also doensn't fix reliably the failure on i?86. Is your alpha
> failure on lto branch or on trunk?
It is on the trunk. However, I have
--- Comment #20 from rguenther at suse dot de 2009-08-30 11:25 ---
Subject: Re: FAIL:
ext/pb_ds/regression/hash_data_map_rand.cc
On Sat, 29 Aug 2009, ubizjak at gmail dot com wrote:
> --- Comment #19 from ubizjak at gmail dot com 2009-08-29 19:52 ---
> Sigh, the patch doesn'
--- Comment #19 from ubizjak at gmail dot com 2009-08-29 19:52 ---
Sigh, the patch doesn't fix alpha failure :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-08-28 19:39
---
Fixed.
(bah, it didn't fix all the others ...)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-08-28 19:36
---
Subject: Bug 41058
Author: rguenth
Date: Fri Aug 28 19:36:05 2009
New Revision: 151176
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151176
Log:
2009-08-28 Richard Guenther
PR lto/41058
--- Comment #16 from jason at redhat dot com 2009-08-28 13:03 ---
Subject: Re: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
On 08/28/2009 06:59 AM, rguenth at gcc dot gnu dot org wrote:
> Jason - might there be any reason this is not correct?
Looks fine to me.
--
http://gcc.g
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-08-28 10:59
---
Index: cp/cp-gimplify.c
===
--- cp/cp-gimplify.c(revision 151156)
+++ cp/cp-gimplify.c(working copy)
@@ -853,6 +853,15 @@ cp_genericize_r (tre
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-08-28 10:41
---
It seems that on trunk the swap
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 = (s
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-08-28 10:16
---
This pattern happens more often in pb_ds.
If I replace the casts by static_cast<>s and const_cast<>s the problem
persists though. I do not see that the frontend produces a FIELD_DECL
for the Eq_Fn base of hash_eq
17 matches
Mail list logo
