http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-13
13:22:40 UTC ---
Note I need to keep reverting this patch to do any substantial builds.
I hear it's also failing for other too.
Any progress in fixing it? Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679
Bug #: 50679
Summary: Linux kernel LTO tracking bug
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #11 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-08
16:47:54 UTC ---
Created attachment 25445
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25445
patchkit
I tested this patchkit which implements most of the ideas from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50666
Bug #: 50666
Summary: bad error reporting for TMPDIR full
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Attachment #25445|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #14 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-08
21:10:13 UTC ---
Thanks for the review. Fixed the accounting
I'll leave the xmalloc_failed hook out for now: it would need a retry
path which is somewhat complicated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
--- Comment #11 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-08
23:27:02 UTC ---
I just checked and the problem is still there with
4.7.0 20111002
xorq%fs:40, %rax
jne .L4
addq$120, %rsp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-09
02:31:38 UTC ---
Looked at this now again
debug_function doesn't work. TDF_UID was also not available, but i hardcoded
it.
(gdb) call debug_function (cfun-decl, 18)
(gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-09
04:05:52 UTC ---
i changed the code now to save ret_val in a volatile global.
This is a bit better
(gdb) p saved_ret_val
$5 = (volatile tree) 0x2afc557b68c0
(gdb) p result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50302
--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07
14:40:02 UTC ---
Sorry yes my mistake.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #10 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07
14:44:10 UTC ---
To track the pattern you can simply use strace or ftrace (I did ftrace)
I checked the kernel code now and if the madvise is big enough it won't
split up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-06
14:49:19 UTC ---
Easy case = constant expressions as index?
Would the frontend be able to handle
short array[1];
i = 1;
array[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
Bug #: 50636
Summary: GC in large LTO builds cause excessive fragmentation
in memory map
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50639
Bug #: 50639
Summary: -flto=jobserver broken on large LTO build
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-06
21:31:56 UTC ---
I would prefer to free in 2MB chunks if possible
I was experimenting with increasing the quire size from 1 to 2MB so that a
modern
kernel with transparent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-06
21:46:32 UTC ---
If it's a 2MB page then madvise MADV_DONTNEED will split it if it's not
2MB aligned. It would be good to optimize the freeing pattern so that this
happens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Bug #: 50644
Summary: ICE in set_is_used added today
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||matz at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07
05:47:54 UTC ---
*** Bug 50302 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
--- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07
05:50:40 UTC ---
*** Bug 50511 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50511
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50302
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07
05:52:08 UTC ---
Honza, I think that is fixed now, correct?
I should probably drop my workarounds but haven't yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
Bug #: 50624
Summary: detecting array overflows regressed
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-05
18:56:24 UTC ---
Thanks.
It's not a pure regression. Even 4.5 misses some easy cases:
especially the local stack array case, which should be in theory really easy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-04
13:22:09 UTC ---
Hmm, are you saying gdb fooled me?
Any other suggestions how to debug it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
Bug #: 50602
Summary: ICE in tree_nrv, at tree-nrv.c:155 during large LTO
build
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Version|unknown |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50587
Bug #: 50587
Summary: ICE init_range_entry, at tree-ssa-reassoc.c:1698
caused by recent change
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-30
23:35:29 UTC ---
Can't say I'm a fan of adding such a heavy weight sequence into
an intrinsic. Maybe better to simply leave out the intrinsics that
cannot be implemented
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...
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.
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.
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
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
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.
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
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?
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)
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.
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50511
Bug #: 50511
Summary: gcc lto streamer in fragments memory badly
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-13
16:00:24 UTC ---
I haven't tried 32bit or GCOV recently, so not sure. I can try next time.
I was still stuck on the other problem with the confused linker plugin ids.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50302
Bug #: 50302
Summary: inefficient float-double conversion in AVX with
-mtune=generic
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49341
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-13
02:45:50 UTC ---
Thanks for fixing. I should have gotten it done earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-09
16:06:34 UTC ---
Hmm, it's hard to see how my patch could have caused this.
It doesn't really change any RTL.
Does the test case even use global registers?
I don't see any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-07
08:15:35 UTC ---
It seems GCOV is not the only cause. I just got the malloc corruption
again when building for 32bit (instead of 64bit), but still with gcov disabled.
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
Summary: ICE in gimple_ic on profile feedback build
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06
09:12:25 UTC ---
Created attachment 2
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=2
profile feedback input file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06
09:50:49 UTC ---
Thanks I'll drop the noreturn as workaround
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06
10:39:32 UTC ---
If you use my command line and just supply any random object files
for the ones specified it should reproduce I think.
If not i'll upload my builddir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-05
23:43:07 UTC ---
FWIW I just commented out the offending assert and the option works
now.
Is that the correct fix?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
Summary: -fdump-ipa-cgraph leads to ICE in
generate_canonical_option, at opts-common.c:303
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-04
19:56:15 UTC ---
Some updates:
I tried with a fresh compiler (20110604). Same malloc assert
I also checked with a somewhat older compiler (from around May 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-04
20:57:59 UTC ---
I found a workaround: disabling -fcoverage-arcs (gcov) makes it go
away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-04
22:13:34 UTC ---
Some investigation:
This depends heavily on the command line used.
A simple test with a hello world works.
On my kernel build when I strip the lto link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
Summary: malloc corruption in large lto1-wpa run during inline
edge heap resize
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Summary: excessive hash table allocation for large lto build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-12
16:16:19 UTC ---
I will try.
BTW this was a much larger test case (allyesconfig), the tarball I sent you
is a much more limited config.
Normally noone uses allyesconfig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-12
16:22:30 UTC ---
looks like the revert is really needed, i just ran out of memory
even on the small config on the large memory system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
Summary: ICE in inline_merge_summary during linux kernel LTO
build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-10
16:37:17 UTC ---
Some more information from gdb. So it follows some pointer in the VEC
that is NULL
(gdb) p edge
$1 = (struct cgraph_edge *) 0x7f1ce05d90d0
(gdb) p edge-uid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-10
20:49:28 UTC ---
I uploaded a (large) test case to
http://firstfloor.org/~andi/lto-kernel.tar.bz2
Run R2 in the directory after pointing the script to the right gcc binary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47311
--- Comment #19 from Andi Kleen andi-gcc at firstfloor dot org 2011-01-17
19:59:23 UTC ---
Sounds like a valgrind bug to me. It should know that the string instruction
does not examine the values after the terminator character and the length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-01-08
23:16:25 UTC ---
slim lto will take some time (next stage1)
i also plan to drop most of the code because with forced plugin
the elf code in collect2 should not be needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-01-08
23:56:48 UTC ---
And to add: if you have more fixes for -fno-lto please add them now,
don't wait.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
Summary: -flto -fno-lto does not disable lto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-12
14:19:00 UTC ---
Same bug seems to be in the code generating phase
gcc -O2 -flto -fno-lto object.o
does code generation even if object.o has fallback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Summary: Linux libgo compilation fails when a libnet is
already installed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-05
22:58:12 UTC ---
BTW I specified a different prefix than /usr, so libtool looked into the wrong
directory anyways here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|RESOLVED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2010-10-26
08:01:01 UTC ---
Thanks.
Unrolling seems to be part of it, but not all. I rebuilt/retrained with
-fno-unroll-loops
Trained:
textdata bss dec hex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2010-10-26
10:28:34 UTC ---
Interesting tidbit: the file containing r600_kms_blit_copy -- which grew most
--
didn't get any profile feedback during training, there was no data file.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
Summary: profile feedback causes 20% linux kernel binary growth
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46055
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2010-10-17
22:28:09 UTC ---
Could simply mark the variable volatile?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45871
Summary: lto bootstrap miscompiles expmed.c1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo:
for function pointers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet
org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-10 08:50 ---
Created an attachment (id=21763)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21763action=view)
testcase, compiled with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
--- Comment #6 from andi-gcc at firstfloor dot org 2010-09-02 07:01 ---
Cannot reproduce this anymore with the latest changes.
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
in libcpp breaks LTO bootstrap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host
in libcpp breaks LTO bootstrap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-01 10:14 ---
Working on a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:15 ---
Yes, I have most of a patch already, but will add the check value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #3 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** Bug 45477 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** This bug has been marked as a duplicate of 45475 ***
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #5 from andi-gcc at firstfloor dot org 2010-09-01 17:05 ---
Patch fixing it went in
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #8 from andi-gcc at firstfloor dot org 2010-08-31 09:32 ---
Sorry this is not fixed yet, only partially. Still working on the last bits,
in particular passthrough of non LTOed code like assembler functions.
--
andi-gcc at firstfloor dot org changed:
What
does not enable instrumentation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
--- Comment #15 from andi-gcc at firstfloor dot org 2010-07-27 06:56
---
I'm working on a solution for the lost code problem. It will require
-ffunction/data-sections so that it can be undone section by section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #13 from andi-gcc at firstfloor dot org 2010-07-21 15:21
---
I know I lost some assembler files, but I think I didn't lose all of them.
Some assembler code is still there. Any suggestion how to fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
301 - 400 of 485 matches
Mail list logo
