public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/50568] New: [4.7 Regression] Massive LTO failures
@ 2011-09-29 15:50 hjl.tools at gmail dot com
2011-09-29 15:55 ` [Bug lto/50568] " hjl.tools at gmail dot com
` (33 more replies)
0 siblings, 34 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 15:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
Bug #: 50568
Summary: [4.7 Regression] Massive LTO failures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: hjl.tools@gmail.com
On Linux/x86, revision 179350 has massive LTO failures:
FAIL: c-c++-common/guality/pr43141.c -O2 -flto (internal compiler error)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto (internal compiler error)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto (test for excess errors)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto (test for excess errors)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (internal
compiler error)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (internal
compiler error)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (test for
excess errors)
FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (test for
excess errors)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto (test for
excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c -O2 -flto
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-mul.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto -flto-partition=none
(internal compiler error)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/complex-sign-sub.c -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto (internal compiler error)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto (internal compiler error)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto (test for excess errors)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto (test for excess errors)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto -flto-partition=none (internal
compiler error)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto -flto-partition=none (internal
compiler error)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto -flto-partition=none (test for
excess errors)
FAIL: c-c++-common/torture/pr42834.c -O2 -flto -flto-partition=none (test for
excess errors)
FAIL: g++.dg/ipa/pr46984.C (internal compiler error)
FAIL: g++.dg/ipa/pr46984.C (test for excess errors)
...
Revision 179346 is OK.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
@ 2011-09-29 15:55 ` hjl.tools at gmail dot com
2011-09-29 16:02 ` andi-gcc at firstfloor dot org
` (32 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 15:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andi-gcc at firstfloor dot
| |org
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 15:50:30 UTC ---
It may only happen on Linux/ia32.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
2011-09-29 15:55 ` [Bug lto/50568] " hjl.tools at gmail dot com
@ 2011-09-29 16:02 ` andi-gcc at firstfloor dot org
2011-09-29 16:04 ` hjl.tools at gmail dot com
` (31 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 16:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #2 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-09-29 15:58:26 UTC ---
Looking...
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
2011-09-29 15:55 ` [Bug lto/50568] " hjl.tools at gmail dot com
2011-09-29 16:02 ` andi-gcc at firstfloor dot org
@ 2011-09-29 16:04 ` hjl.tools at gmail dot com
2011-09-29 16:18 ` hjl.tools at gmail dot com
` (30 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 16:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 15:59:54 UTC ---
I got
lto1: internal compiler error: resolution sub id ffffffff not in object file^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (2 preceding siblings ...)
2011-09-29 16:04 ` hjl.tools at gmail dot com
@ 2011-09-29 16:18 ` hjl.tools at gmail dot com
2011-09-29 18:12 ` hjl.tools at gmail dot com
` (29 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 16:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.7.0
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 16:02:04 UTC ---
It is caused by revision 179348:
http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00967.html
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (3 preceding siblings ...)
2011-09-29 16:18 ` hjl.tools at gmail dot com
@ 2011-09-29 18:12 ` hjl.tools at gmail dot com
2011-09-29 18:16 ` andi-gcc at firstfloor dot org
` (28 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 17:56:25 UTC ---
The problem is in
Breakpoint 2, process_symtab (data=0xffffccc0,
name=0x82041fe ".gnu.lto_.symtab.f1d7150d3f9de9cb", offset=1325, length=56)
at /export/gnu/import/git/gcc/lto-plugin/lto-plugin.c:813
813 secdata = xmalloc (length);
(gdb) p s
$1 = 0x820420e ".f1d7150d3f9de9cb"
(gdb) p obj->out->id
$2 = 4294967295
(gdb) p/x obj->out->id
$3 = 0xffffffff
(gdb)
We got 32bit overflow with 64bit random seed.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (4 preceding siblings ...)
2011-09-29 18:12 ` hjl.tools at gmail dot com
@ 2011-09-29 18:16 ` andi-gcc at firstfloor dot org
2011-09-29 18:18 ` hjl.tools at gmail dot com
` (27 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 18:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #6 from Andi Kleen <andi-gcc at firstfloor dot org> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (5 preceding siblings ...)
2011-09-29 18:16 ` andi-gcc at firstfloor dot org
@ 2011-09-29 18:18 ` hjl.tools at gmail dot com
2011-09-29 18:19 ` hjl.tools at gmail dot com
` (26 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> 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 value.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (6 preceding siblings ...)
2011-09-29 18:18 ` hjl.tools at gmail dot com
@ 2011-09-29 18:19 ` hjl.tools at gmail dot com
2011-09-29 18:20 ` andi-gcc at firstfloor dot org
` (25 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 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 for lto plugin.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (7 preceding siblings ...)
2011-09-29 18:19 ` hjl.tools at gmail dot com
@ 2011-09-29 18:20 ` andi-gcc at firstfloor dot org
2011-09-29 18:21 ` andi-gcc at firstfloor dot org
` (24 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 18:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #9 from Andi Kleen <andi-gcc at firstfloor dot org> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (8 preceding siblings ...)
2011-09-29 18:20 ` andi-gcc at firstfloor dot org
@ 2011-09-29 18:21 ` andi-gcc at firstfloor dot org
2011-09-29 18:26 ` hjl.tools at gmail dot com
` (23 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 18:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #10 from Andi Kleen <andi-gcc at firstfloor dot org> 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.
uint64_t is probably fine too.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (9 preceding siblings ...)
2011-09-29 18:21 ` andi-gcc at firstfloor dot org
@ 2011-09-29 18:26 ` hjl.tools at gmail dot com
2011-09-29 18:28 ` hjl.tools at gmail dot com
` (22 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (10 preceding siblings ...)
2011-09-29 18:26 ` hjl.tools at gmail dot com
@ 2011-09-29 18:28 ` hjl.tools at gmail dot com
2011-09-29 18:29 ` hjl.tools at gmail dot com
` (21 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> 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/lto-plugin.c
for 64bit id.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (11 preceding siblings ...)
2011-09-29 18:28 ` hjl.tools at gmail dot com
@ 2011-09-29 18:29 ` hjl.tools at gmail dot com
2011-09-29 18:29 ` andi-gcc at firstfloor dot org
` (20 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 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 plugin.
That won't work since splay-tree doesn't support 64bit key on
32bit hosts. We can't use 64bit id for LTO.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (12 preceding siblings ...)
2011-09-29 18:29 ` hjl.tools at gmail dot com
@ 2011-09-29 18:29 ` andi-gcc at firstfloor dot org
2011-09-29 18:35 ` andi-gcc at firstfloor dot org
` (19 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 18:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #14 from Andi Kleen <andi-gcc at firstfloor dot org> 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 platforms supporting
plugins (windows, darwin, linux)
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (13 preceding siblings ...)
2011-09-29 18:29 ` andi-gcc at firstfloor dot org
@ 2011-09-29 18:35 ` andi-gcc at firstfloor dot org
2011-09-29 18:45 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 18:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #15 from Andi Kleen <andi-gcc at firstfloor dot org> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (15 preceding siblings ...)
2011-09-29 18:45 ` hjl.tools at gmail dot com
@ 2011-09-29 18:45 ` hjl.tools at gmail dot com
2011-09-29 20:47 ` andi-gcc at firstfloor dot org
` (16 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |34835
--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 18:29:19 UTC ---
(In reply to comment #15)
> 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.
See PR 34835.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (14 preceding siblings ...)
2011-09-29 18:35 ` andi-gcc at firstfloor dot org
@ 2011-09-29 18:45 ` hjl.tools at gmail dot com
2011-09-29 18:45 ` hjl.tools at gmail dot com
` (17 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 18:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (16 preceding siblings ...)
2011-09-29 18:45 ` hjl.tools at gmail dot com
@ 2011-09-29 20:47 ` andi-gcc at firstfloor dot org
2011-09-29 20:55 ` hjl.tools at gmail dot com
` (15 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 20:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #18 from Andi Kleen <andi-gcc at firstfloor dot org> 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 fix all the problems with the splay tree, by allocating
the key separately.
Can you give it a test please? Thanks
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (17 preceding siblings ...)
2011-09-29 20:47 ` andi-gcc at firstfloor dot org
@ 2011-09-29 20:55 ` hjl.tools at gmail dot com
2011-09-29 22:23 ` hjl.tools at gmail dot com
` (14 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 20:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> 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 problems with the splay tree, by allocating
> the key separately.
>
2 comments:
1. We should use long long consistently in both lto-plugin
and lto. We can add a check to enable LTO only if long long is
supported on host.
2. Can we avoid indirect penalty on 64bit hosts?
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (19 preceding siblings ...)
2011-09-29 22:23 ` hjl.tools at gmail dot com
@ 2011-09-29 22:23 ` hjl.tools at gmail dot com
2011-09-29 22:28 ` hjl.tools at gmail dot com
` (12 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 22:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> 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 since lto-plugin.c can use
long long for symbol ID encoded in section name by
lto.c even if HOST_WIDE_INT is 32bit.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (18 preceding siblings ...)
2011-09-29 20:55 ` hjl.tools at gmail dot com
@ 2011-09-29 22:23 ` hjl.tools at gmail dot com
2011-09-29 22:23 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 22:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (20 preceding siblings ...)
2011-09-29 22:23 ` hjl.tools at gmail dot com
@ 2011-09-29 22:28 ` hjl.tools at gmail dot com
2011-09-29 22:53 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 22:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> 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 problems with the splay tree, by allocating
> the key separately.
>
> Can you give it a test please? Thanks
Doesn't work:
gdb) bt
#0 0x080def1f in lto_splay_compare_ids (a=484680112, b=153199512)
at /export/gnu/import/git/gcc/gcc/lto/lto.c:1109
#1 0x08d26ee8 in splay_tree_splay (sp=0x921a240, key=484680112)
at /export/gnu/import/git/gcc/libiberty/splay-tree.c:149
#2 0x08d274ef in splay_tree_lookup (sp=0x921a240, key=484680112)
at /export/gnu/import/git/gcc/libiberty/splay-tree.c:456
#3 0x080dec01 in create_subid_section_table (slot=0x921a168, data=0x921a240)
at /export/gnu/import/git/gcc/gcc/lto/lto.c:1022
#4 0x08d21882 in htab_traverse_noresize (htab=0x919bf50,
callback=0x80debb4 <create_subid_section_table>, info=0x921a240)
at /export/gnu/import/git/gcc/libiberty/hashtab.c:784
#5 0x08d218ea in htab_traverse (htab=0x919bf50,
callback=0x80debb4 <create_subid_section_table>, info=0x921a240)
at /export/gnu/import/git/gcc/libiberty/hashtab.c:800
#6 0x080def8a in lto_file_read (file=0x919c9f0, resolution_file=0x9219fe0,
count=0xffffd08c) at /export/gnu/import/git/gcc/gcc/lto/lto.c:1132
#7 0x080e5a43 in read_cgraph_and_symbols (nfiles=1, fnames=0x91a8060)
at /export/gnu/import/git/gcc/gcc/lto/lto.c:2496
#8 0x080e6196 in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:2809
#9 0x085dadfb in compile_file ()
at /export/gnu/import/git/gcc/gcc/toplev.c:565
#10 0x085dcf2e in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1925
#11 0x085dd0b0 in toplev_main (argc=16, argv=0x9181450)
---Type <return> to continue, or q <return> to quit---
at /export/gnu/import/git/gcc/gcc/toplev.c:2001
#12 0x080e8be7 in main (argc=16, argv=0xffffd224)
at /export/gnu/import/git/gcc/gcc/main.c:36
(gdb)
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (21 preceding siblings ...)
2011-09-29 22:28 ` hjl.tools at gmail dot com
@ 2011-09-29 22:53 ` hjl.tools at gmail dot com
2011-09-29 23:17 ` andi-gcc at firstfloor dot org
` (10 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 22:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 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 */
- nd = splay_tree_lookup (file_ids, id);
+ nd = splay_tree_lookup (file_ids, (splay_tree_key)&id);
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (22 preceding siblings ...)
2011-09-29 22:53 ` hjl.tools at gmail dot com
@ 2011-09-29 23:17 ` andi-gcc at firstfloor dot org
2011-09-29 23:21 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 23:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #24 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-09-29 23:06:35 UTC ---
Thanks. Does it work with this change?
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (23 preceding siblings ...)
2011-09-29 23:17 ` andi-gcc at firstfloor dot org
@ 2011-09-29 23:21 ` hjl.tools at gmail dot com
2011-09-29 23:22 ` hjl.tools at gmail dot com
` (8 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 23:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-29 23:16:20 UTC ---
Created attachment 25386
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25386
A better patch
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (24 preceding siblings ...)
2011-09-29 23:21 ` hjl.tools at gmail dot com
@ 2011-09-29 23:22 ` hjl.tools at gmail dot com
2011-09-29 23:32 ` andi-gcc at firstfloor dot org
` (7 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-29 23:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #26 from H.J. Lu <hjl.tools at gmail dot com> 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_ids (splay_tree_key a, splay_tree_key b)
{
unsigned HOST_WIDE_INT *ai = (unsigned HOST_WIDE_INT *)a;
unsigned HOST_WIDE_INT *bi = (unsigned HOST_WIDE_INT *)b;
return *ai - *bi;
}
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (25 preceding siblings ...)
2011-09-29 23:22 ` hjl.tools at gmail dot com
@ 2011-09-29 23:32 ` andi-gcc at firstfloor dot org
2011-09-29 23:34 ` andi-gcc at firstfloor dot org
` (6 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 23:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #27 from Andi Kleen <andi-gcc at firstfloor dot org> 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)
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (26 preceding siblings ...)
2011-09-29 23:32 ` andi-gcc at firstfloor dot org
@ 2011-09-29 23:34 ` andi-gcc at firstfloor dot org
2011-09-30 0:33 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-29 23:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #28 from Andi Kleen <andi-gcc at firstfloor dot org> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (27 preceding siblings ...)
2011-09-29 23:34 ` andi-gcc at firstfloor dot org
@ 2011-09-30 0:33 ` hjl.tools at gmail dot com
2011-09-30 0:45 ` andi-gcc at firstfloor dot org
` (4 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-30 0:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #29 from H.J. Lu <hjl.tools at gmail dot com> 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_compare_ids returns int. *ai - *bi may be 0xfffffff10000000
and lto_splay_compare_ids returns > 0 instead of < 0.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (28 preceding siblings ...)
2011-09-30 0:33 ` hjl.tools at gmail dot com
@ 2011-09-30 0:45 ` andi-gcc at firstfloor dot org
2011-09-30 6:00 ` hjl.tools at gmail dot com
` (3 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: andi-gcc at firstfloor dot org @ 2011-09-30 0:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #30 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-09-29 23:33:52 UTC ---
Okay. Can you post the patch then?
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (29 preceding siblings ...)
2011-09-30 0:45 ` andi-gcc at firstfloor dot org
@ 2011-09-30 6:00 ` hjl.tools at gmail dot com
2011-09-30 15:57 ` hjl at gcc dot gnu.org
` (2 subsequent siblings)
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2011-09-30 6:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://gcc.gnu.org/ml/gcc-p
| |atches/2011-09/msg01977.htm
| |l
--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-30 00:57:59 UTC ---
A patch posted at
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01977.html
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (30 preceding siblings ...)
2011-09-30 6:00 ` hjl.tools at gmail dot com
@ 2011-09-30 15:57 ` hjl at gcc dot gnu.org
2011-10-10 15:14 ` rguenth at gcc dot gnu.org
2021-08-24 13:10 ` hjl.tools at gmail dot com
33 siblings, 0 replies; 35+ messages in thread
From: hjl at gcc dot gnu.org @ 2011-09-30 15:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #32 from hjl at gcc dot gnu.org <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/lto
2011-09-30 H.J. Lu <hongjiu.lu@intel.com>
Andi Kleen <ak@linux.intel.com>
PR lto/50568
* lto.c (lto_splay_tree_delete_id): New.
(lto_splay_tree_compare_ids): Likewise.
(lto_splay_tree_lookup): Likewise.
(lto_splay_tree_id_equal_p): Likewise.
(lto_splay_tree_insert): Likewise.
(lto_splay_tree_new): Likewise.
(lto_resolution_read): Change id to unsigned HOST_WIDE_INT.
Use lto_splay_tree_id_equal_p and lto_splay_tree_lookup.
(create_subid_section_table): Use lto_splay_tree_lookup and
lto_splay_tree_insert.
(lto_file_read): Use lto_splay_tree_new.
lto-plugin/
2011-09-30 H.J. Lu <hongjiu.lu@intel.com>
Andi Kleen <ak@linux.intel.com>
PR lto/50568
* lto-plugin.c (sym_aux): Change id to unsigned long long.
(plugin_symtab): Likewise.
(dump_symtab): Likewise.
(resolve_conflicts): Likewise.
(process_symtab): Likewise.
Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/lto-plugin.c
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (31 preceding siblings ...)
2011-09-30 15:57 ` hjl at gcc dot gnu.org
@ 2011-10-10 15:14 ` rguenth at gcc dot gnu.org
2021-08-24 13:10 ` hjl.tools at gmail dot com
33 siblings, 0 replies; 35+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-10-10 15:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #33 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-10 15:14:07 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug lto/50568] [4.7 Regression] Massive LTO failures
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
` (32 preceding siblings ...)
2011-10-10 15:14 ` rguenth at gcc dot gnu.org
@ 2021-08-24 13:10 ` hjl.tools at gmail dot com
33 siblings, 0 replies; 35+ messages in thread
From: hjl.tools at gmail dot com @ 2021-08-24 13:10 UTC (permalink / raw)
To: gcc-bugs
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
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |MOVED
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2021-08-24 13:10 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-29 15:50 [Bug lto/50568] New: [4.7 Regression] Massive LTO failures hjl.tools at gmail dot com
2011-09-29 15:55 ` [Bug lto/50568] " hjl.tools at gmail dot com
2011-09-29 16:02 ` andi-gcc at firstfloor dot org
2011-09-29 16:04 ` hjl.tools at gmail dot com
2011-09-29 16:18 ` hjl.tools at gmail dot com
2011-09-29 18:12 ` hjl.tools at gmail dot com
2011-09-29 18:16 ` andi-gcc at firstfloor dot org
2011-09-29 18:18 ` hjl.tools at gmail dot com
2011-09-29 18:19 ` hjl.tools at gmail dot com
2011-09-29 18:20 ` andi-gcc at firstfloor dot org
2011-09-29 18:21 ` andi-gcc at firstfloor dot org
2011-09-29 18:26 ` hjl.tools at gmail dot com
2011-09-29 18:28 ` hjl.tools at gmail dot com
2011-09-29 18:29 ` hjl.tools at gmail dot com
2011-09-29 18:29 ` andi-gcc at firstfloor dot org
2011-09-29 18:35 ` andi-gcc at firstfloor dot org
2011-09-29 18:45 ` hjl.tools at gmail dot com
2011-09-29 18:45 ` hjl.tools at gmail dot com
2011-09-29 20:47 ` andi-gcc at firstfloor dot org
2011-09-29 20:55 ` hjl.tools at gmail dot com
2011-09-29 22:23 ` hjl.tools at gmail dot com
2011-09-29 22:23 ` hjl.tools at gmail dot com
2011-09-29 22:28 ` hjl.tools at gmail dot com
2011-09-29 22:53 ` hjl.tools at gmail dot com
2011-09-29 23:17 ` andi-gcc at firstfloor dot org
2011-09-29 23:21 ` hjl.tools at gmail dot com
2011-09-29 23:22 ` hjl.tools at gmail dot com
2011-09-29 23:32 ` andi-gcc at firstfloor dot org
2011-09-29 23:34 ` andi-gcc at firstfloor dot org
2011-09-30 0:33 ` hjl.tools at gmail dot com
2011-09-30 0:45 ` andi-gcc at firstfloor dot org
2011-09-30 6:00 ` hjl.tools at gmail dot com
2011-09-30 15:57 ` hjl at gcc dot gnu.org
2011-10-10 15:14 ` rguenth at gcc dot gnu.org
2021-08-24 13:10 ` hjl.tools at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).