[Bug lto/50568] [4.7 Regression] Massive LTO failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 Bug 50568 depends on bug 34835, which changed state. Bug 34835 Summary: splay-tree doesn't support 64bit value on 32bit host https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34835 What|Removed |Added ---

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #32 from hjl at gcc dot gnu.org 2011-09-30 15:48:56 UTC --- Author: hjl Date: Fri Sep 30 15:48:51 2011 New Revision: 179395 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179395 Log: Use 64bit integer for LTO symbol ID. gcc/l

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p |

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #30 from Andi Kleen 2011-09-29 23:33:52 UTC --- Okay. Can you post the patch then?

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #29 from H.J. Lu 2011-09-29 23:31:13 UTC --- (In reply to comment #28) > I don't understand which overflow you refer to. Can you please clarify? > > afaik a - b is the standard way to write these comparison functions. lto_splay_comp

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #28 from Andi Kleen 2011-09-29 23:22:17 UTC --- I don't understand which overflow you refer to. Can you please clarify? afaik a - b is the standard way to write these comparison functions.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #27 from Andi Kleen 2011-09-29 23:21:12 UTC --- Hmm is that just for efficiency or did you fix another bug? (not worrying about efficiency too much because this tree has only one entry per input file)

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #26 from H.J. Lu 2011-09-29 23:19:49 UTC --- (In reply to comment #24) > Thanks. Does it work with this change? I posted a different patch to avoid indirect reference on 64bit host and avoid overflow in static int lto_splay_compare_

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #25 from H.J. Lu 2011-09-29 23:16:20 UTC --- Created attachment 25386 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25386 A better patch

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #24 from Andi Kleen 2011-09-29 23:06:35 UTC --- Thanks. Does it work with this change?

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #23 from H.J. Lu 2011-09-29 22:26:34 UTC --- (In reply to comment #9) > Created attachment 25381 [details] > Use long long in lto-plugin > > Can you please test this patch? > You missed: /* Find hash table of sub module id */ -

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #22 from H.J. Lu 2011-09-29 22:23:53 UTC --- (In reply to comment #18) > Created attachment 25384 [details] > fix + splay tree > > I have some unrelated trouble with a 32bit bootstrap currently. > > This patch should fix all the pro

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #21 from H.J. Lu 2011-09-29 22:20:02 UTC --- (In reply to comment #20) > HOST_WIDE_INT may not be 64bit on 32bit host. > But long long is 64bit. I don't think it is > correct to use HOST_WIDE_INT in lto. It may not be a problem sinc

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #20 from H.J. Lu 2011-09-29 22:14:28 UTC --- HOST_WIDE_INT may not be 64bit on 32bit host. But long long is 64bit. I don't think it is correct to use HOST_WIDE_INT in lto.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #19 from H.J. Lu 2011-09-29 20:44:44 UTC --- (In reply to comment #18) > Created attachment 25384 [details] > fix + splay tree > > I have some unrelated trouble with a 32bit bootstrap currently. > > This patch should fix all the pro

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #18 from Andi Kleen 2011-09-29 20:36:50 UTC --- Created attachment 25384 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25384 fix + splay tree I have some unrelated trouble with a 32bit bootstrap currently. This patch should fi

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #17 from H.J. Lu 2011-09-29 18:34:38 UTC --- Also I don't believe it is 100% safe to use %x for printf/scanf on 64bit integer even on 64bit hosts. I think 64bit random seed change should be reverted for now.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu changed: What|Removed |Added Depends on||34835 --- Comment #16 from H.J. Lu 2011-09-29

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #15 from Andi Kleen 2011-09-29 18:28:18 UTC --- Hmm good point. Maybe the splay tree can be fixed. Otherwise have to use 32bit ids on 32bit, but then the risk of collisions is higher again.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #14 from Andi Kleen 2011-09-29 18:27:11 UTC --- But that's what I did? % diffstat plugin-fix lto-plugin.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) I don't see why long long cannot be used on the platfo

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #13 from H.J. Lu 2011-09-29 18:26:06 UTC --- (In reply to comment #8) > Created attachment 25380 [details] > A patch > > This patch works for me. But I don't think it is correct. > We need a way to specify HOST_WIDE_INT for lto plug

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #12 from H.J. Lu 2011-09-29 18:21:17 UTC --- (In reply to comment #9) > Created attachment 25381 [details] > Use long long in lto-plugin > > Can you please test this patch? > It won't work since you also need to update lto-plugin/l

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #11 from H.J. Lu 2011-09-29 18:19:30 UTC --- HOST_WIDE_INT is needed for gcc, libcpp and plug-in. We should have a central host-wide-int.m4 to define all HOST_WIDE_INT related macros.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #10 from Andi Kleen 2011-09-29 18:19:02 UTC --- I did the same patch (with long long) I think using long long here is ok because lto-plugin only builds on modern and non weird hosts and they should all have long long anyways. uint6

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #9 from Andi Kleen 2011-09-29 18:17:08 UTC --- Created attachment 25381 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25381 Use long long in lto-plugin Can you please test this patch? Thanks.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #8 from H.J. Lu 2011-09-29 18:16:03 UTC --- Created attachment 25380 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25380 A patch This patch works for me. But I don't think it is correct. We need a way to specify HOST_WIDE_INT

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #7 from H.J. Lu 2011-09-29 18:11:50 UTC --- (In reply to comment #6) > I don't see the problem on a 64bit bootstrap-lto. > > I guess i must have written some 32bit unsafe code. We can't use 64bit random seed when LTO expects 32bit v

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #6 from Andi Kleen 2011-09-29 18:03:21 UTC --- I don't see the problem on a 64bit bootstrap-lto. I guess i must have written some 32bit unsafe code.

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #5 from H.J. Lu 2011-09-29 17:56:25 UTC --- The problem is in Breakpoint 2, process_symtab (data=0xccc0, name=0x82041fe ".gnu.lto_.symtab.f1d7150d3f9de9cb", offset=1325, length=56) at /export/gnu/import/git/gcc/lto-plugi

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #4 from H.J. Lu 2011-09-29 1

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #3 from H.J. Lu 2011-09-29 15:59:54 UTC --- I got lto1: internal compiler error: resolution sub id not in object file^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #2 from Andi Kleen 2011-09-29 15:58:26 UTC --- Looking...

[Bug lto/50568] [4.7 Regression] Massive LTO failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu changed: What|Removed |Added CC||andi-gcc at firstfloor dot |