[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-19 14:40:53 UTC --- I'm not 100% sure which stage generates them, but I have lots of cc*.o and some others (.res etc.) left over after the LTRANS failure. After two failures in a row i always have a full /.
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-19 15:28:07 UTC --- I'm not, this was a normal lto bootstrap without any special flags
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #16 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-20 00:10:57 UTC --- Fixed now on Linux (when the kernel supports MADV_DONTNEED) Other OS still likely suffer from this likely though.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-20 05:53:49 UTC --- Can someone mark this as a regression please? This still keeps crashing and crashing. I don't see why I need to debug a clear regression when I already bisected it. IMHO this should be reverted.
[Bug other/50783] New: builtin c++ demanger does not handle clones
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50783 Bug #: 50783 Summary: builtin c++ demanger does not handle clones Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org From a unrelated double bootstrap failure: In function 'rtx_def* gen_movsfcc(rtx, rtx, rtx, rtx)': vs In function 'int _ZL8recog_61P7rtx_defS0_Pi.isra.35(rtvec_def**, rtx)': Seems like the function with .isra.35 was not correctly demangled.
[Bug lto/50786] New: temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 Bug #: 50786 Summary: temporary files not cleaned up on LTO errors Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When there's a problem during LTRANS (in my cases ICE, but could be something else) the temporary LTO files in TEMPDIR do not always seem to get cleaned up. Since they can be fairly large this can lead to filled up / file systems and other problems when they accumulate. Not sure who is supposed to clean this up. The driver or the lto plugin?
[Bug tree-optimization/50644] ICE in set_is_used added today
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.
[Bug lto/50679] New: Linux kernel LTO tracking bug
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 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Meta bug to track various problems encountered while building the Linux kernel with LTO
[Bug lto/50620] undefined reference errors / csmith lto testing
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 at firstfloor dot ||org --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-09 14:33:18 UTC --- I see a similar problem in a large LTO build (at least Honza thinks it's the same)
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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 this bug, unfortunately still the same problem (with 20% threshold and madvise) From the core file I see a lot of 2-3 page holes still: 65218 load65205 00019000 2ae45c515000 bfea1000 2**12 CONTENTS, ALLOC, LOAD 65219 load65206 00018000 2ae45c52f000 bfeba000 2**12 CONTENTS, ALLOC, LOAD 65220 load65207 00013000 2ae45c548000 bfed2000 2**12 CONTENTS, ALLOC, LOAD 65221 load65208 00019000 2ae45c55d000 bfee5000 2**12 CONTENTS, ALLOC, LOAD 65222 load65209 1000 2ae45c577000 bfefe000 2**12 CONTENTS, ALLOC, LOAD 65223 load65210 00044000 2ae45c579000 bfeff000 2**12 CONTENTS, ALLOC, LOAD 65224 load65211 0003d000 2ae45c5be000 bff43000 2**12 CONTENTS, ALLOC, LOAD 65225 load65212 00021000 2ae45c5fc000 bff8 2**12 CONTENTS, ALLOC, LOAD 65226 load65213 6000 2ae45c61e000 bffa1000 2**12 CONTENTS, ALLOC, LOAD 65227 load65214 0002d000 2ae45c625000 bffa7000 2**12 CONTENTS, ALLOC, LOAD 65228 load65215 00041000 2ae45c653000 bffd4000 2**12 CONTENTS, ALLOC, LOAD 65229 load65216 b000 2ae45c695000 c0015000 2**12 CONTENTS, ALLOC, LOAD 65230 load65217 1000 2ae45c6a1000 c002 2**12 CONTENTS, ALLOC, LOAD 65231 load65218 f000 2ae45c6a3000 c0021000 2**12 CONTENTS, ALLOC, LOAD 65232 load65219 1000 2ae45c6b3000 c003 2**12 CONTENTS, ALLOC, LOAD 65233 load65220 00031000 2ae45c6b5000 c0031000 2**12 CONTENTS, ALLOC, LOAD 65234 load65221 0001a000 2ae45c6e7000 c0062000 2**12 CONTENTS, ALLOC, LOAD 65235 load65222 0001c000 2ae45c702000 c007c000 2**12 CONTENTS, ALLOC, LOAD
[Bug lto/50666] New: bad error reporting for TMPDIR full
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 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When $TMPDIR gets full for a LTO build you just get ld exited with error 1 which is very unhelpful. It would be better if there was a real error message for this.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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 is obsolete|| --- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-08 19:54:59 UTC --- Created attachment 25446 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25446 updated patchkit This version seems to work. I am at under 1000 mappings now for the case that failed previously.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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. If it's needed would probably just add another separate threshold that forces munmapping. BTW i also filed a bug on the glibc bug this triggered: http://sourceware.org/bugzilla/show_bug.cgi?id=13276
[Bug middle-end/25957] -fstack-protector code on i386/x86_64 can be improved.
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 .cfi_remember_state .cfi_def_cfa_offset 8 ret .L4: .cfi_restore_state .p2align 4,,6 call__stack_chk_fail .cfi_endproc .LFE0: unnecessary wasteful alignment for the call to abort. The basic block should be marked cold.
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
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) neither the other call (gdb) call print_generic_expr(stderr, result, 1 8) (gdb) Looking at the code 0x0075a827 tree_nrv()+311:test %rax,%rax 0x0075a82a tree_nrv()+314:je 0x75a7f2 gsi_next 0x0075a82c tree_nrv()+316:cmp%rax,%rbx 0x0075a82f tree_nrv()+319:je 0x75a7f2 gsi_next 0x0075a831 tree_nrv()+321:mov$0xbe3bb7,%edx 0x0075a836 tree_nrv()+326:mov$0x9b,%esi 0x0075a83b tree_nrv()+331:mov$0xbe3b7a,%edi 0x0075a840 tree_nrv()+336:callq 0xb488e0 fancy_abort(char const*, int, char const*) 0x0075a845 tree_nrv()+341:nopl (%rax) I'm in the fancy_abort When I go up and print $rax I get 0 (gdb) p $rax $11 = 0 But this cannot be because the test tested it for 0. Perhaps the unwind information below is wrong?
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
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 $6 = (tree_node *) 0x2afbfb754a00 Still not sure how to print them, maybe stderr is broken. Looking at raw output I see one of them is a VAR_DECL and the other a RESULT_DECL (gdb) p result-decl_minimal.uid $9 = 83837 (gdb) p saved_ret_val-decl_minimal.uid $10 = 3599083 (gdb) p cfun-decl-decl_minimal.uid $3 = 83835 Searching for the second uid in the dump files I see it first in 045i.whole-program: bb 7: return D.3599083; and the first doesn't appear in any file (that means the current pass added it?) The third is first in 049.inline
[Bug target/50302] inefficient float-double conversion in AVX with -mtune=generic
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.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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 the 2MB page. So doing it aggressively should be ok, but still it may be beneficial to skip it for very scattered pages. I suspect other OS don't have MADV_DONTNEED, they would probably need Honza's pool idea. I did a prototype patch now, will be testing it.
[Bug c/50624] detecting array overflows regressed
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]
[Bug other/50636] New: GC in large LTO builds cause excessive fragmentation in memory map
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 Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When doing a very large LTO build I fail with out of virtual memory Some investigation showed the problem was not actually running out of memory, but gcc excessively fragmenting its memory map. The Linux kernel has a default limit of 64k mappings per process and the fragmentation exceeded that. This lead to gc mmap allocations failing and other problems. A workaround is to increase /proc/sys/vm/max_map_count Looking at /proc/$(pidof lto1)/maps I see there are lots of 1-3 page holes between other anonymousmemory. I think that's caused by ggc-pages free_pages() function freeing too early and in too small chunks (and perhaps LTO garbage collecting too much?)
[Bug other/50639] New: -flto=jobserver broken on large LTO build
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 Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org On a -j8 Linux kernel LTO build with -flto=jobserver I always end up with make[3]: *** read jobs pipe: No such file or directory. Stop. make[3]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/local/bin/ld-plugin: lto-wrapper failed at the final link stage. The link is actually succeeding, but something confuses jobserver It works with -flto=8. The message comes from make. It could be a regression, but it's hard to say because older much builds usually ran into other problems.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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 huge pages can always get a huge page. If the freeing also happens in the same chunks the kernel can keep the 2MB pages together. But yes MADV_DONTNEED makes sense too.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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 rarely. I will try to do some numbers how much 2MB pages improves performance. If yes we could also do a MADV_HUGEPAGE by default. But short term fix would be simply to have a threshold for freepages before freeing?
[Bug tree-optimization/50644] New: ICE in set_is_used added today
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 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Since updating to today's trunk I get a ICE in set_is_used while building a LTOed linux kernel. Yesterday it didn't happen Running a bisect. Here's the crash #7 signal handler called #8 set_is_used (var=value optimized out) at +../../gcc/gcc/tree-flow-inline.h:562 #9 mark_all_vars_used_1 (var=value optimized out) at +../../gcc/gcc/tree-ssa-live.c:379 #10 0x00860b3e in walk_tree_1 (tp=0x2b11d2f00c00, func=0x7a4390 +mark_all_vars_used_1(tree*, int*, void*), data=0x4296a40, pset=0x0, lh=0) at ../../gcc/gcc/tree.c:10448 #11 0x00860f89 in walk_tree_1 (tp=0x2b11d2efacd0, func=0x7a4390 +mark_all_vars_used_1(tree*, int*, void*), data=0x4296a40, pset=0x0, lh=0) at ../../gcc/gcc/tree.c:10526 #12 0x007a4eb5 in mark_all_vars_used (data=value optimized out, +expr_p=value optimized out) at ../../gcc/gcc/tree-ssa-live.c:595 #13 remove_unused_locals (data=value optimized out, expr_p=value optimized +out) at ../../gcc/gcc/tree-ssa-live.c:798 #14 0x0068c268 in execute_function_todo (data=Unhandled dwarf +expression opcode 0xf3 ) at ../../gcc/gcc/passes.c:1695 #15 0x0068d114 in execute_todo (flags=2132516) at +../../gcc/gcc/passes.c:1741 #16 0x0068f3ce in execute_one_ipa_transform_pass (ipa_pass=0x10ac6e0, +node=0x2b11e3116ea0) at ../../gcc/gcc/passes.c:1919 #17 execute_all_ipa_transforms (ipa_pass=0x10ac6e0, node=0x2b11e3116ea0) at +../../gcc/gcc/passes.c:1947 #18 0x0075fd20 in tree_rest_of_compilation (fndecl=0x2b11d2ed7300) at +../../gcc/gcc/tree-optimize.c:413 #19 0x0051b8a6 in cgraph_expand_function (node=0x2b11e3116ea0) at +../../gcc/gcc/cgraphunit.c:1805 #20 0x0051d182 in cgraph_output_in_order () at +../../gcc/gcc/cgraphunit.c:1962 #21 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2136 ... (gdb) up #8 set_is_used (var=value optimized out) at +../../gcc/gcc/tree-flow-inline.h:562 562 ann-used = true; (gdb) p ann $1 = (var_ann_d *) 0x0
[Bug tree-optimization/50644] ICE in set_is_used added today
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 dot gnu.org --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-06 23:53:57 UTC --- Problem is caused by commit 6d3d8bf0e6cb73524be01e28cb82a484cd3d11fd Author: matz matz@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Oct 6 15:18:12 2011 + * tree-flow.h (get_var_ann): Don't declare. * tree-flow-inline.h (get_var_ann): Remove. (set_is_used): Use var_ann, not get_var_ann. * tree-dfa.c (add_referenced_var): Inline body of get_var_ann. * tree-profile.c (gimple_gen_edge_profiler): Call find_referenced_var_in. (gimple_gen_interval_profiler): Ditto. (gimple_gen_pow2_profiler): Ditto. (gimple_gen_one_value_profiler): Ditto. (gimple_gen_average_profiler): Ditto. (gimple_gen_ior_profiler): Ditto. (gimple_gen_ic_profiler): Ditto plus call add_referenced_var. (gimple_gen_ic_func_profiler): Call add_referenced_var. * tree-mudflap.c (execute_mudflap_function_ops): Call add_referenced_var. I cannot give you a small test case because it needs a full LTO builddir
[Bug lto/44992] ld -r breaks LTO
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 Resolution||FIXED --- Comment #10 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:42:50 UTC --- I consider this fixed now because everything I need works together with HJ's binutils. Mainstream binutils will hopefull catch up eventually.
[Bug lto/46905] -flto -fno-lto does not disable lto
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 Resolution||FIXED --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:43:55 UTC --- AFAIK this works now.
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
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 Resolution||FIXED --- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:45:29 UTC --- Fixed for quite some time
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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. ***
[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize
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 Resolution||FIXED --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:49:13 UTC --- Haven't seen this for some time with different builds, so it's probably fixed
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
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. ***
[Bug lto/50511] gcc lto streamer in fragments memory badly
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 Resolution||DUPLICATE --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:50:40 UTC --- Was likely the same problem as 50636 *** This bug has been marked as a duplicate of bug 50636 ***
[Bug target/50302] inefficient float-double conversion in AVX with -mtune=generic
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 Resolution||DUPLICATE --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-07 05:47:54 UTC --- Was actually a dup of the GC problem. I tried fixing the one-off cache, but it didn't fix the fragmentation *** This bug has been marked as a duplicate of bug 50636 ***
[Bug lto/44463] whopr does not work with weak functions
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
[Bug c/50624] New: detecting array overflows regressed
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: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Created attachment 25424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25424 overflow tester The attached program tests 5 different array overflows that the compiler should be able to detect at compile time. gcc 4.5 detects 2 out of 5 with -O2 -Wall: overflow.c:14:7: warning: array subscript is above array bounds overflow.c:22:12: warning: array subscript is above array bounds Current mainline detects zero. gcc version 4.7.0 20111002 (experimental) (GCC)
[Bug c/50624] detecting array overflows regressed
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.
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
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?
[Bug tree-optimization/50602] New: ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
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
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
I get this at the end of a large 32bit LTO build. Cannot give you a small test
case unless you want the full builddir. Bisect is difficult because
the build relies on some recent other fixes.
But I have a core file:
#6 0x00b47eb4 in fancy_abort (file=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/gcc/diagnostic.c:893
#7 0x0075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
#8 0x0068d7ab in execute_one_pass (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2064
#9 0x0068dae5 in execute_pass_list (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2119
#10 0x0075df39 in tree_rest_of_compilation (fndecl=0x2b84d3ea6900) at
../../gcc/gcc/tree-optimize.c:420
#11 0x0051ad36 in cgraph_expand_function (node=0x2b84e28a7360) at
../../gcc/gcc/cgraphunit.c:1805
#12 0x0051c612 in cgraph_output_in_order () at
../../gcc/gcc/cgraphunit.c:1962
#13 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2136
#14 0x004cb7c5 in lto_main () at ../../gcc/gcc/lto/lto.c:2872
...
#7 0x0075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
155 gcc_assert (ret_val == result);
(gdb) p ret_val
$3 = (tree_node *) 0x0
(gdb) pt result
type = union tree_node {
tree_base base;
tree_typed typed;
tree_common common;
tree_int_cst int_cst;
tree_real_cst real_cst;
tree_fixed_cst fixed_cst;
tree_vector vector;
tree_string string;
tree_complex complex;
tree_identifier identifier;
tree_decl_minimal decl_minimal;
tree_decl_common decl_common;
tree_decl_with_rtl decl_with_rtl;
tree_decl_non_common decl_non_common;
tree_parm_decl parm_decl;
tree_decl_with_vis decl_with_vis;
tree_var_decl var_decl;
tree_field_decl field_decl;
tree_label_decl label_decl;
tree_result_decl result_decl;
tree_const_decl const_decl;
tree_type_decl type_decl;
tree_function_decl function_decl;
tree_translation_unit_decl translation_unit_decl;
tree_type_common type_common;
tree_type_with_lang_specific type_with_lang_specific;
tree_type_non_common type_non_common;
tree_list list;
tree_vec vec;
tree_exp exp;
tree_ssa_name ssa_name;
tree_block block;
tree_binfo binfo;
tree_statement_list stmt_list;
tree_constructor constructor;
tree_omp_clause omp_clause;
tree_optimization_option optimization;
tree_target_option target_option;
} *
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
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 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-03 16:40:47 UTC --- Seen with gcc version 4.7.0 20111002 (experimental) (GCC)
[Bug tree-optimization/50587] New: ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change
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: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Jakub, your recent change PR tree-optimization/46309 * fold-const.c (make_range, merge_ranges): Remove prototypes. (make_range_step): New function. (make_range): Use it. * tree.h (make_range_step): New prototypes. * Makefile.in (tree-ssa-reassoc.o): Depend on $(DIAGNOSTIC_CORE_H). * tree-ssa-reassoc.c: Include diagnostic-core.h. (struct range_entry): New type. (init_range_entry, range_entry_cmp, update_range_test, optimize_range_tests): New functions. (reassociate_bb): Call optimize_range_tests. * gcc.dg/pr46309.c: New test. breaks my LTO kernel builds. I get a lot of internal compiler error: in init_range_entry, at tree-ssa-reassoc.c:1698 in different files. With the patch reverted things are fine
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
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 with loops? If someone wants a loop they better open code it. It would be nice if you implemented the ors, nands and ands with bts, btr etc if the second argument is a constant and only has one bit set.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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...
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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)
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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?
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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)
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
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?
[Bug lto/50511] New: gcc lto streamer in fragments memory badly
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 Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org I ran into a problem while testing LTO on a quite large project with a lot of object files: the lto streamer fragmented the memory map badly by constantly mapping and unmapping the input files with mmap. I ended up with a memory map with lots of 2 page holes between mappings. Eventually it bumped into the default 64k max number of mappings limit on Linux and errored out because mmap failed. Workaround was to increase this limit (sysctl -w vm.max_map_count = 20) However gcc should be more efficient in its mappings. I think the problem is the one off cache in lto_file_read() being too dumb. Looking into a fix.
[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize
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.
[Bug target/50302] New: inefficient float-double conversion in AVX with -mtune=generic
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
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
I noticed that with AVX and -mtune=generic and converting a single float to a
double gcc still generates
vunpcklps reg,reg
vcvtps2pd reg,reg
instead of the more straight forward and likely more power efficient
vcvtss2sd reg,reg
AFAIK the first sequence was only needed on some older AMD CPUs with SSE
to avoid a conversion penalty, does it really still make sense for AVX?
Perhaps that should be fixed for tune=generic ?
Test case:
#include stdio.h
float a = 1, b = 2;
float c;
int main(void)
{
c = a + b;
printf(%f\n, c);
return 0;
}
[Bug testsuite/49341] [4.7 Regression] FAIL: gcc.dg/20051207-3.c and gcc.dg/tls/section-1.c
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.
[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap
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 in native/fdlibm/strtod.c The only thing that could possibly have a side effect is storing the decl in a global array, but even that should be benign. Are you sure you bisected right?
[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize
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 probably for the other build disabling gcov just hid it. lto1: malloc.c:3551: munmap_chunk: Assertion `ret == 0' failed. lto1: internal compiler error: Aborted Very nasty. Any ideas how to track that down? Is valgrind supposed to work?
[Bug gcov-profile/49299] New: ICE in gimple_ic on profile feedback build
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: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Created attachment 24443 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24443 usage.i With 4.6.1 20110606 (and 4.7) and /pkg/gcc-4.6-110606/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/cc1 -fpreprocessed usage.i -quiet -dumpbase usage.c -mtune=generic -march=x86-64 -auxbase-strip usage.o -g -O2 -Wall -version -fprofile-use -o usage.s I get GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ecc22bd7305923b0c90b3c641509cfa5 Program received signal SIGSEGV, Segmentation fault. gimple_ic (all=23, count=23, prob=1, icall_stmt=0x76b79aa0, direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:1156 1156 (gdb) bt #0 gimple_ic (all=23, count=23, prob=1, icall_stmt=0x76b79aa0, direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:1156 #1 gimple_ic_transform (all=23, count=23, prob=1, icall_stmt=0x76b79aa0, direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:1274 #2 gimple_value_profile_transformations (all=23, count=23, prob=1, icall_stmt=0x76b79aa0, direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:528 #3 0x00767e2b in tree_profiling () at ../../gcc/gcc/tree-profile.c:484 #4 0x00689399 in execute_one_pass (pass=0x1097a20) at ../../gcc/gcc/passes.c:1556 #5 0x00689a3a in execute_ipa_pass_list (pass=0x1097a20) at ../../gcc/gcc/passes.c:1923 #6 0x00898efc in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1783 #7 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1855 #8 0x008990aa in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1096 #9 0x0049e405 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9871 #10 0x0071a848 in compile_file () at ../../gcc/gcc/toplev.c:591 #11 do_compile () at ../../gcc/gcc/toplev.c:1900 #12 toplev_main () at ../../gcc/gcc/toplev.c:1963 #13 0x771dfa7d in __libc_start_main () from /lib64/libc.so.6 #14 0x0048de09 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build
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
[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build
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
[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303
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, but it's large.
[Bug lto/48978] excessive hash table allocation for large lto build
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 Resolution||FIXED --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06 11:05:47 UTC --- With the latest tree it's bearable, but still very slow. But at least I don't run regularly out of memory anymore.
[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303
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?
[Bug other/49284] New: -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303
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 Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org gcc version 4.7.0 20110604 (experimental) (GCC) Passing -fdump-ipa-cgraph to a IPA final build gives: lto1: internal compiler error: in generate_canonical_option, at opts-common.c:303
[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize
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) It segfaulted eventually too, so I suspect the problem has been there for longer.
[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize
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.
[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303
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 command line down I get the error with gcc47 -fdump-cgraph-ipa -nostdlib -fuse-linker-plugin -flto=jobserver -fwhole-program -Wl,-m,elf_x86_64 -Wl,--build-id -o .tmp_vmlinux1 -Wl,-T,arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o arch/x86/kernel/head_64.o and not with (last file deleted) gcc47 -fdump-cgraph-ipa -nostdlib -fuse-linker-plugin -flto=jobserver -fwhole-program -Wl,-m,elf_x86_64 -Wl,--build-id -o .tmp_vmlinux1 -Wl,-T,arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
[Bug middle-end/49282] New: malloc corruption in large lto1-wpa run during inline edge heap resize
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 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org A large lto1-wpa run with 20110603 results now in malloc.c:3551: munmap_chunk: Assertion `ret == 0' failed. on x86-64-linux. When I run with MALLOC_CHECK_=2 it seems to get a bit further, but eventually aborts (and deadlocks because the abort-internal_error handler calls malloc again) Here's the original trace for the malloc that aborts (with MALLOC_CHECK_=2) Any suggestions for patches to try to revert? Note full bisect is difficult because this run depends on some earlier fixes. Not uploading a test case currently because it's quite large. #10 0x2b236701d4e5 in raise () from /lib64/libc.so.6 #11 0x2b236701e9b0 in abort () from /lib64/libc.so.6 #12 0x2b236705df1a in ?? () from /lib64/libc.so.6 #13 0x2b23670640d7 in ?? () from /lib64/libc.so.6 #14 0x00b2684d in xrealloc (oldmem=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/libiberty/xmalloc.c:179 #15 0x0083e528 in vec_heap_o_reserve_1 (vec=0x2b23ea786010, reserve=Unhandled dwarf ex pression opcode 0xf3 ) at ../../gcc/gcc/vec.c:313 #16 0x005ea27f in VEC_inline_edge_summary_t_heap_reserve_exact ( alloc_=value optimized out, vec_=value optimized out) at ../../gcc/gcc/ipa-inline.h:128 #17 VEC_inline_edge_summary_t_heap_safe_grow (alloc_=value optimized out, vec_=value optimized out) at ../../gcc/gcc/ipa-inline.h:128 #18 VEC_inline_edge_summary_t_heap_safe_grow_cleared (alloc_=value optimized out, vec_=value optimized out) at ../../gcc/gcc/ipa-inline.h:128 #19 inline_summary_alloc (alloc_=value optimized out, vec_=value optimized out) at ../../gcc/gcc/ipa-inline-analysis.c:646 #20 0x005ea3c1 in inline_edge_duplication_hook (src=0x2b2499f41680, dst=0x2b243e2d7680, data=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/ipa-inline-analysis.c:853 #21 0x004e995c in cgraph_call_edge_duplication_hooks (cs2=0x2b243e2d7680, cs1=0x2b2499f41680) at ../../gcc/gcc/cgraph.c:376 #22 cgraph_clone_edge (cs2=0x2b243e2d7680, cs1=0x2b2499f41680) at ../../gcc/gcc/cgraph.c:2127 #23 0x004e9c1d in cgraph_clone_node (n=0x2b2499f286f0, decl=0x2b2395b15500, count=Unha ndled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/cgraph.c:2196 #24 0x005eeb9f in clone_inlined_nodes (e=0x2b2499f4a6e8, duplicate=1 '\001', update_original=1 '\001', overall_size=0x102e488)
[Bug lto/48978] excessive hash table allocation for large lto build
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
Resolution|FIXED |
--- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-13
17:09:24 UTC ---
Sorry the problem is still there even with your revert and current trunk,
triggerable with the large config build. Just the small config works
now.
Breakpoint 1, xmalloc_failed (size=8589934312) at
../../gcc/libiberty/xmalloc.c:118
118 {
(gdb) bt
#0 xmalloc_failed (size=8589934312) at ../../gcc/libiberty/xmalloc.c:118
#1 0x00b1b428 in xcalloc (nelem=1073741789, elsize=8) at
../../gcc/libiberty/xmalloc.c:164
#2 0x00b16216 in htab_expand (htab=0x15bfba0) at
../../gcc/libiberty/hashtab.c:558
#3 0x00b16b2a in htab_find_slot_with_hash (htab=0x15bfba0,
element=0x7fffb0473140, hash=4078607638,
insert=INSERT) at ../../gcc/libiberty/hashtab.c:653
#4 0x005b0584 in lookup_type_pair (ob_p=0x1022380,
visited_p=0x1022370, t1=value optimized out,
t2=value optimized out) at ../../gcc/gcc/gimple.c:3284
#5 0x005b0ea1 in gtc_visit (sccstate_obstack=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3556
#6 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3473
#7 0x005b09d4 in gimple_types_compatible_p_1 (t1=0x2b6db95d1930,
t2=0x2b6e244635e8, p=0x1983bda30,
sccstack=0x7fffb0473568, sccstate=0x197a0cbb0,
sccstate_obstack=0x7fffb0473570) at ../../gcc/gcc/gimple.c:3716
#8 0x005b0edd in gtc_visit (sccstate_obstack=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3569
#9 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3473
#10 0x005b0b86 in gimple_types_compatible_p_1 (t1=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3833
#11 0x005b0edd in gtc_visit (sccstate_obstack=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3569
#12 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3473
#13 0x005b09d4 in gimple_types_compatible_p_1 (t1=0x2b6db95d17e0,
t2=0x2b6e24463498, p=0x1983bda10,
sccstack=0x7fffb0473568, sccstate=0x197a0cbb0,
sccstate_obstack=0x7fffb0473570) at ../../gcc/gcc/gimple.c:3716
#14 0x005b0edd in gtc_visit (sccstate_obstack=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3569
#15 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3473
#16 0x005b0b86 in gimple_types_compatible_p_1 (t1=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:3833
[Bug lto/48978] New: excessive hash table allocation for large lto build
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 AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) (GCC) on a 18GB machine. It ended with lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 bytes Since a 7+GB single malloc seems somewhat excessive I put a break point on xmalloc_failed. It looks like the hash tables are growing too aggressively? #0 xmalloc_failed (size=8589934312) at ../../gcc/libiberty/xmalloc.c:118 #1 0x00b1b8a8 in xcalloc (nelem=1073741789, elsize=8) at ../../gcc/libiberty/xmalloc.c:164 #2 0x00b16696 in htab_expand (htab=0x11949c0) at ../../gcc/libiberty/hashtab.c:558 #3 0x00b16faa in htab_find_slot_with_hash (htab=0x11949c0, element=0x7fff64c7d0c0, hash=2685589897, insert=INSERT) at ../../gcc/libiberty/hashtab.c:653 #4 0x005a9701 in lookup_type_pair (ob_p=0x1022380, visited_p=0x1022370, t1=value optimized out, t2=value optimized out) at ../../gcc/gcc/gimple.c:3284 #5 0x005b1235 in gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3557 #6 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3473 #7 0x005b0d69 in gimple_types_compatible_p_1 (t1=0x2aff61dc3b28, t2=0x2affd032b150, p=0x197c33a70, sccstack=0x7fff64c7d188, sccstate=0x9817ee40, sccstate_obstack=0x7fff64c7d190) at ../../gcc/gcc/gimple.c:3717 #8 0x005af31e in gimple_types_compatible_p (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c:3987 #9 gimple_type_eq (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c: #10 0x00b16f1e in htab_find_slot_with_hash (htab=0x2aff56172a10, element=0x2affd032b150, hash=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/libiberty/hashtab.c:687 #11 0x005af4cd in gimple_register_type (t=0x2affd032b150) at ../../gcc/gcc/gimple.c:4480 #12 0x0049c670 in lto_ft_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:296 #13 0x0049c6b9 in lto_ft_decl_minimal (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:309 #14 lto_ft_decl_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:319 ---Type return to continue, or q return to quit--- #15 0x0049d25d in lto_ft_field_decl (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:364 #16 lto_fixup_types (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:542 #17 0x0049ddd0 in uniquify_nodes (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:618 #18 lto_read_decls (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:697 #19 lto_file_finalize (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:921 #20 lto_create_files_from_ids (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:939 #21 0x00b1b6cf in splay_tree_foreach_helper (data=0x7fff64c7d520, fn=0x49dca0 lto_create_files_from_ids, node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:242 #22 splay_tree_foreach (data=0x7fff64c7d520, fn=0x49dca0 lto_create_files_from_ids, node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:566 #23 0x0049f53c in lto_file_read (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:979 #24 read_cgraph_and_symbols (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2321 #25 lto_main (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2621 #26 0x006cf4aa in compile_file () at ../../gcc/gcc/toplev.c:570 #27 do_compile () at ../../gcc/gcc/toplev.c:1905 #28 toplev_main () at ../../gcc/gcc/toplev.c:1977 #29 0x2aff56c32a7d in __libc_start_main () from /lib64/libc.so.6 #30 0x00486c49 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug lto/48978] excessive hash table allocation for large lto build
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 kernels (they barely boot), but they are a good stress tester for the compiler. Still I suspect the hash table expansion algorithms are not optimal. If you're already in the GB range you shouldn't be doubling anymore...
[Bug lto/48978] excessive hash table allocation for large lto build
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.
[Bug lto/48952] New: ICE in inline_merge_summary during linux kernel LTO build
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 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When running a Linux kernel LTO build with recent mainline (gcc version 4.7.0 20110510 (experimental) (GCC)) I get a segfault during the final lto-wpa phase In gdb I get Program received signal SIGSEGV, Segmentation fault. inline_merge_summary (edge=0x7f1ce05d90d0) at ../../gcc/gcc/ipa-inline-analysis.c:2025 2025 ipa_get_cs_argument_count (IPA_EDGE_REF (edge (gdb) bt #0 inline_merge_summary (edge=0x7f1ce05d90d0) at ../../gcc/gcc/ipa-inline-analysis.c:2025 #1 0x0085b079 in inline_call (e=0x7f1ce05d90d0, update_original=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/ipa-inline-transform.c:185 #2 0x00854561 in inline_small_functions () at ../../gcc/gcc/ipa-inline.c:1451 #3 ipa_inline () at ../../gcc/gcc/ipa-inline.c:1643 #4 0x0063c509 in execute_one_pass (pass=0xfff720) at ../../gcc/gcc/passes.c:1556 #5 0x0063cbca in execute_ipa_pass_list (pass=0xfff720) at ../../gcc/gcc/passes.c:1922 #6 0x0049ffe5 in do_whole_program_analysis () at ../../gcc/gcc/lto/lto.c:2517 #7 lto_main () at ../../gcc/gcc/lto/lto.c:2629 #8 0x006ccc4a in compile_file (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:570 #9 do_compile (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:1928 #10 toplev_main (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:2000 #11 0x003bc6e1ee5d in __libc_start_main (main=0x4a29e0 main, argc=16, ubp_av=0x7fff62bc8e28, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fff62bc8e18) at libc-start.c:226 #12 0x00486f99 in _start () (gdb) The input files are very large. I can supply them on demand. They also require special binutils currently (HJ's latest version)
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
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 $2 = 38701 (gdb) disp/3i $pc 1: x/3i $pc = 0x859bdc inline_merge_summary+188: mov0x8(%rbx,%rdx,1),%ecx 0x859be0 inline_merge_summary+192: test %ecx,%ecx 0x859be2 inline_merge_summary+194: je 0x859cdb inline_merge_summary+443 (gdb) p $rbx $3 = 0 (gdb) p $rdx $4 = 619216 (gdb)
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
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.
[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
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.
[Bug lto/46905] -flto -fno-lto does not disable lto
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 anymore.
[Bug lto/46905] -flto -fno-lto does not disable lto
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.
[Bug lto/46905] New: -flto -fno-lto does not disable lto
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: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org gcc -flto -fno-lto hello.c generates LTO objects. It should not. In large makefiles it's often convenient to use -fno... to disable something for only specific files.
[Bug lto/46905] -flto -fno-lto does not disable lto
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
[Bug bootstrap/46812] Linux libgo compilation fails when a libnet is already installed
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 --- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-10 13:23:08 UTC --- Yes works now. Thanks.
[Bug bootstrap/46812] Linux libgo compilation fails when a libnet is already installed
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 Resolution|FIXED | --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-09 17:05:51 UTC --- The problem is still there as of trunk Dec9. I verified the patch below is in the Changelog. libtool: compile: /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto ../../../gcc/libgo/go/crypto/tls/alert.go ../../../gcc/libgo/go/crypto/tls/ca_set.go ../../../gcc/libgo/go/crypto/tls/common.go ../../../gcc/libgo/go/crypto/tls/conn.go ../../../gcc/libgo/go/crypto/tls/handshake_client.go ../../../gcc/libgo/go/crypto/tls/handshake_messages.go ../../../gcc/libgo/go/crypto/tls/handshake_server.go ../../../gcc/libgo/go/crypto/tls/prf.go ../../../gcc/libgo/go/crypto/tls/tls.go -fPIC -o crypto/.libs/libtls.a.o ../../../gcc/libgo/go/crypto/tls/conn.go:11:5: error: /usr/lib/../lib64/libnet.so exists but does not contain any Go export data Can someone please reopen the bug?
[Bug bootstrap/46812] New: Linux libgo compilation fails when a libnet is already installed
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 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org I tried to bootstrap a trunk gcc with go enabled on a OpenSUSE system. This failed with: set -e; rm -f crypto/rsa.gox.o; /home/andi/gcc/git/obj/./gcc/xgcc -B/home/andi/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include-r -nostdlib -o crypto/rsa.gox.o -Wl,--whole-archive crypto/librsa.a; objcopy -j .go_export crypto/rsa.gox.o crypto/rsa.gox.tmp; mv -f crypto/rsa.gox.tmp crypto/rsa.gox; rm -f crypto/rsa.gox.o rm -f `echo crypto/libx509.a | sed -e 's|/lib|/|' -e 's/\.a/.gox/'`; test -d crypto || /bin/mkdir -p crypto; rm -f crypto/libx509.a; files=`echo ../../../gcc/libgo/go/crypto/x509/x509.go asn1.gox big.gox container/vector.gox crypto/rsa.gox crypto/sha1.gox hash.gox os.gox strings.gox time.gox | sed -e 's/[^ ]*\.gox//g'`; if /bin/sh ./libtool --tag GO --mode=compile /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto -o crypto/libx509.a.o $files; then ar rc crypto/libx509.a crypto/libx509.a.o; else exit 1; fi libtool: compile: /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto ../../../gcc/libgo/go/crypto/x509/x509.go -fPIC -o crypto/.libs/libx509.a.o libtool: compile: /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto ../../../gcc/libgo/go/crypto/x509/x509.go -o crypto/libx509.a.o /dev/null 21 set -e; rm -f crypto/x509.gox.o; /home/andi/gcc/git/obj/./gcc/xgcc -B/home/andi/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include-r -nostdlib -o crypto/x509.gox.o -Wl,--whole-archive crypto/libx509.a; objcopy -j .go_export crypto/x509.gox.o crypto/x509.gox.tmp; mv -f crypto/x509.gox.tmp crypto/x509.gox; rm -f crypto/x509.gox.o rm -f `echo crypto/libtls.a | sed -e 's|/lib|/|' -e 's/\.a/.gox/'`; test -d crypto || /bin/mkdir -p crypto; rm -f crypto/libtls.a; files=`echo ../../../gcc/libgo/go/crypto/tls/alert.go ../../../gcc/libgo/go/crypto/tls/ca_set.go ../../../gcc/libgo/go/crypto/tls/common.go ../../../gcc/libgo/go/crypto/tls/conn.go ../../../gcc/libgo/go/crypto/tls/handshake_client.go ../../../gcc/libgo/go/crypto/tls/handshake_messages.go ../../../gcc/libgo/go/crypto/tls/handshake_server.go ../../../gcc/libgo/go/crypto/tls/prf.go ../../../gcc/libgo/go/crypto/tls/tls.go bufio.gox bytes.gox container/list.gox crypto/hmac.gox crypto/md5.gox crypto/rc4.gox crypto/rand.gox crypto/rsa.gox crypto/sha1.gox crypto/subtle.gox crypto/x509.gox encoding/pem.gox fmt.gox hash.gox io.gox io/ioutil.gox net.gox os.gox strings.gox sync.gox time.gox | sed -e 's/[^ ]*\.gox//g'`; if /bin/sh ./libtool --tag GO --mode=compile /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto -o crypto/libtls.a.o $files; then ar rc crypto/libtls.a crypto/libtls.a.o; else exit 1; fi libtool: compile: /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101205/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto
[Bug bootstrap/46812] Linux libgo compilation fails when a libnet is already installed
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.
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
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 Resolution|FIXED | --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2010-11-29 18:51:19 UTC --- Reopen it if it's really still broken.
[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth
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 filename 127744891198572 1357680 15330741 e9edb5 vmlinux Untrained: 111364521200876 1357552 13694880 d0f7a0 ../obj-work2/vmlinux So it's only 13% difference now, but still a lot. function old new delta r600_kms_blit_copy 2640 16394 +13754 static.do_con_write- 10163 +10163 static.rv770_startup -9541 +9541 r600_blit_copy 10605 19626 +9021 e1000_setup_copper_link-8894 +8894 kmem_cache_create 1385 10227 +8842 des3_ede_encrypt12038208 +7005 des3_ede_decrypt12038208 +7005
[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth
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 generated lists and cgraph ipa dumps for the feedback, non feedback compilations: dumps: http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-plain http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-feedback listings: http://halobates.de/tmp/20percent/r600_blit_kms.lst-plain http://halobates.de/tmp/20percent/r600_blit_kms.lst-feedback
[Bug middle-end/46176] New: profile feedback causes 20% linux kernel binary growth
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 AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Recent gcc 4.6 snapshot on x86_64-linux. I did an experimental patch to use profile feedback with the Linux kernel With a very simple training run (covering only ~50% of the files partially) Unfortunately recompiling with the feedback data leads to a 20% larger binary. This is compiled using -O2. Trained: textdata bss dec hex filename 136150401202668 1357680 16175388 f6d11c vmlinux Untrained: 111364521200876 1357552 13694880 d0f7a0 vmlinux Comparing the symbols with the largest growth I get: add/remove: 674/2006 grow/shrink: 12172/4139 up/down: 3000900/-510189 (2490711) function old new delta r600_kms_blit_copy 2640 16394 +13754 static.do_con_write- 10681 +10681 r600_blit_copy 10605 21205 +10600 zlib_inflate5459 15261 +9802 static.rv770_startup -9541 +9541 e1000_setup_copper_link-9510 +9510 e1000_diag_test14064 22948 +8884 kmem_cache_create 1385 10227 +8842 I have not analyzed it in detail, but current suspicion is much more aggressive inlining? Note also that a lot of functions were using fallback profiling data because the training load wasn't very good.
[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test
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?
[Bug middle-end/45871] New: lto bootstrap miscompiles expmed.c1
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: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
On x86_64-linux:
Doing a lto bootstrap (BUILD_CONFIG=bootstrap-lto) with current trunk
(last change 2010-10-03 Uros Bizjak ubiz...@gmail.com)
ends with ICEs (for each file tried) on the compilation of
the 32bit libgcc2 in stage2.
It looks like expmed.c is miscompiled for the stage1 compiler and
jumps to a hardcoded NULL:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x009b788b in store_bit_field_1 (str_rtx=value optimized out,
bitsize=15, bitnum=112, fieldmode=VOIDmode,
value=value optimized out, fallback_p=1 '\001') at
../../gcc/gcc/expmed.c:657
#2 0x009b809f in store_bit_field (str_rtx=value optimized out,
bitsize=value optimized out,
bitnum=value optimized out, fieldmode=value optimized out, value=value
optimized out) at ../../gcc/gcc/expmed.c:833
#3 0x00772ffe in store_field (target=0x76a37378, bitsize=15,
bitpos=112, mode=VOIDmode,
exp=value optimized out, type=value optimized out, alias_set=0,
nontemporal=0 '\000') at ../../gcc/gcc/expr.c:5969
#4 store_field (target=0x76a37378, bitsize=15, bitpos=112, mode=VOIDmode,
exp=value optimized out,
type=value optimized out, alias_set=0, nontemporal=0 '\000') at
../../gcc/gcc/expr.c:5820
#5 0x00773b5a in expand_assignment (to=0x76d78600,
from=0x768eee18, nontemporal=0 '\000')
at ../../gcc/gcc/expr.c:4352
#6 expand_assignment (to=0x76d78600, from=0x768eee18, nontemporal=0
'\000') at ../../gcc/gcc/expr.c:4150
#7 0x008ce344 in expand_gimple_stmt_1 (stmt=0x76bcb4b0) at
../../gcc/gcc/cfgexpand.c:1892
#8 expand_gimple_stmt (stmt=0x76bcb4b0) at ../../gcc/gcc/cfgexpand.c:2001
#9 0x008ceda6 in expand_gimple_basic_block (bb=0x76be2b60) at
../../gcc/gcc/cfgexpand.c:3453
#10 0x008d2842 in gimple_expand_cfg () at
../../gcc/gcc/cfgexpand.c:3913
#11 0x00b528bf in execute_one_pass (pass=0xf3ab40) at
../../gcc/gcc/passes.c:1569
#12 0x00b52c95 in execute_pass_list (pass=0xf3ab40) at
../../gcc/gcc/passes.c:1624
#13 0x00c0c624 in tree_rest_of_compilation (fndecl=0x76cd6c00) at
../../gcc/gcc/tree-optimize.c:419
#14 0x00aeca86 in cgraph_expand_function (node=0x76d11160) at
../../gcc/gcc/cgraphunit.c:1477
#15 0x00aedfa2 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1556
#16 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1812
#17 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1743
#18 0x00aee83a in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1020
#19 0x00793803 in c_write_global_declarations () at
../../gcc/gcc/c-decl.c:9747
#20 c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9701
#21 0x00b8807c in compile_file (argc=83, argv=0x7fffdb98) at
../../gcc/gcc/toplev.c:951
#22 do_compile (argc=83, argv=0x7fffdb98) at ../../gcc/gcc/toplev.c:2379
#23 toplev_main (argc=83, argv=0x7fffdb98) at ../../gcc/gcc/toplev.c:2420
(gdb) up
#1 0x009b788b in store_bit_field_1 (str_rtx=value optimized out,
bitsize=15, bitnum=112, fieldmode=VOIDmode,
value=value optimized out, fallback_p=1 '\001') at
../../gcc/gcc/expmed.c:657
657insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT
(bitsize),
(gdb) l
652GET_MODE (value) != BLKmode
653bitsize 0
654GET_MODE_BITSIZE (op_mode) = bitsize
655! ((REG_P (op0) || GET_CODE (op0) == SUBREG)
656 (bitsize + bitpos GET_MODE_BITSIZE (op_mode)))
657insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT
(bitsize),
658 VOIDmode)
659check_predicate_volatile_ok (CODE_FOR_insv, 0, op0, VOIDmode))
660 {
661 int xbitpos = bitpos;
Stepping through it:
It enters the predicate gen_rtx_CONST_INT and returns and then runs
into a hardcoded NULL jump in store_bit_field_1:
(gdb)
0x009df018 in gen_rtx_CONST_INT (mode=value optimized out, arg=15) at
../../gcc/gcc/emit-rtl.c:422
422 }
2: x/3i $pc
= 0x9df018 gen_rtx_CONST_INT+56: retq
0x9df019 gen_rtx_CONST_INT+57: nopl 0x0(%rax)
0x9df020 gen_rtx_CONST_INT+64: mov0x65c431(%rip),%rdi#
0x103b458 const_int_htab.997056
(gdb)
0x009b7882 in store_bit_field_1 (str_rtx=value optimized out,
bitsize=15, bitnum=112, fieldmode=VOIDmode,
value=value optimized out, fallback_p=1 '\001') at
../../gcc/gcc/expmed.c:657
657insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT
(bitsize),
2:
[Bug middle-end/45631] New: devirtualization with profile feedback does not work for function pointers
Following simple example:
#include stdio.h
static void a(void)
{
printf(a\n);
}
static void b(void)
{
printf(b\n);
}
static void __attribute__((noinline)) do_call(void (*p)(void))
{
p();
}
int main(void)
{
int i;
for (i = 0; i 30; i++)
do_call((i%4) 3 ? a : b);
return 0;
}
I compile it with profile feedback and generate feedback data
% gcc -O3 -fprofile-generate x.c
% ./a.out
... output ...
% gcc -O3 -fprofile-use x.c
Examining the output do_call of the final code is just:
00400520 do_call:
400520: ff e7 jmpq *%rdi
But I would have expected the profile feedback code to detect
that a is much more likely than b in the indirect call
and inline a through devirtualization.
--
Summary: devirtualization with profile feedback does not work
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: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
[Bug middle-end/45632] New: const function pointer propagation issues with inlining
The attached test case is testing inlining of const function pointers in a typical OO code written in C situation. The code shows two optimization problems: - a_foo is inlined into main, b_foo is not. The only difference is that new_a() returns a const pointer and new_b() does not. I would have assumed that gcc detects that the pointer coming out of new_b() is const. - p-ops-op2 is never inlined, not even for a, even though the compiler should have enough information to do so (everything that is passed in is const). I assume this is because cloning does not work through function pointers? -- Summary: const function pointer propagation issues with inlining 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: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
[Bug middle-end/45632] const function pointer propagation issues with inlining
--- 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
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug lto/45475] New: target use in libcpp breaks LTO bootstrap
I know I'm at least partly to blame for this :) With a LTO bootstrap I get now /home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode streams do not support the target attribute because of the new __target__ use in libcpp/lex.c -- Summary: target use 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 triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
[Bug lto/45477] New: target use in libcpp breaks LTO bootstrap
I know I'm at least partly to blame for this :) With a LTO bootstrap I get now /home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode streams do not support the target attribute because of the new __target__ use in libcpp/lex.c -- Summary: target use 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 triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
[Bug lto/45477] target use in libcpp breaks LTO bootstrap
--- 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
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
--- 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
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
--- 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
