In the one day between r215702 and 215747 trunk started failing to compile CP2K with '-c -flto=jobserver -fprofile-use '. Several lto instances fail with: /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/core_ae.F:58:0: internal compiler error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:988 SUBROUTINE build_core_ae(matrix_h, matrix_p, force, virial, calculate_forces, use_virial, nder,& ^ 0xb4e8c0 freqs_to_counts_path ../../gcc/gcc/tree-ssa-threadupdate.c:988 0xb4e8c0 ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*) ../../gcc/gcc/tree-ssa-threadupdate.c:1061 0xb4f018 ssa_fixup_template_block ../../gcc/gcc/tree-ssa-threadupdate.c:1301 0xb4f018 traverse_noresize<ssa_local_info_t*, ssa_fixup_template_block> ../../gcc/gcc/hash-table.h:942 0xb4f018 traverse<ssa_local_info_t*, ssa_fixup_template_block> ../../gcc/gcc/hash-table.h:964 0xb4f018 thread_block_1 ../../gcc/gcc/tree-ssa-threadupdate.c:1523 0xb4f4e0 thread_block ../../gcc/gcc/tree-ssa-threadupdate.c:1560 0xb4fd6e thread_through_all_blocks(bool) ../../gcc/gcc/tree-ssa-threadupdate.c:2279 0xbd86ed finalize_jump_threads ../../gcc/gcc/tree-vrp.c:9856 0xbd86ed execute_vrp ../../gcc/gcc/tree-vrp.c:10010 given the combination of lto and profile-use it will be difficult to generate a testcase (other than building full cp2k with profile feedback, which is somewhat involved).
I suspect this is caused by r215739
Yes, this function is new in r215739. I will see if I can trigger it tomorrow. If you have a smaller test case that would be great. Or even if you can give me the gcda file and preprocessed source that will help. Teresa On Tue, Sep 30, 2014 at 9:12 PM, Joost.VandeVondele at mat dot ethz.ch <gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 > > Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |Joost.VandeVondele at mat dot ethz > | |.ch, tejohnson at google dot com > > --- Comment #1 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> --- > I suspect this is caused by r215739 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Teresa Johnson from comment #2) > Yes, this function is new in r215739. I will see if I can trigger it > tomorrow. If you have a smaller test case that would be great. Or even > if you can give me the gcda file and preprocessed source that will > help. this only happens with LTO, so I'm not sure there is easily a source file I can provide (with ~1000 .gdca files). I tried some smaller programs, but didn't see the problem yet.
Created attachment 33636 [details] testcase Here is a relative small testcase: markus@x4 /tmp % g++ -flto -fprofile-use -fno-exceptions -std=gnu++0x -O2 mozilla-xremote-client.ii XRemoteClient.ii /var/tmp/mozilla-central/widget/xremoteclient/mozilla-xremote-client.cpp: In function ‘main’: /var/tmp/mozilla-central/widget/xremoteclient/mozilla-xremote-client.cpp:16:5: internal compiler error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:988 int main(int argc, char **argv) ^ 0xb00cf0 freqs_to_counts_path ../../gcc/gcc/tree-ssa-threadupdate.c:988 0xb00cf0 ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*) ../../gcc/gcc/tree-ssa-threadupdate.c:1061 0xb02260 ssa_fixup_template_block ../../gcc/gcc/tree-ssa-threadupdate.c:1301 0xb02260 traverse_noresize<ssa_local_info_t*, ssa_fixup_template_block> ../../gcc/gcc/hash-table.h:942 0xb02260 traverse<ssa_local_info_t*, ssa_fixup_template_block> ../../gcc/gcc/hash-table.h:964 0xb02260 thread_block_1 ../../gcc/gcc/tree-ssa-threadupdate.c:1523 0xb02994 thread_block ../../gcc/gcc/tree-ssa-threadupdate.c:1560 0xb031dd thread_through_all_blocks(bool) ../../gcc/gcc/tree-ssa-threadupdate.c:2279 0xb856a1 finalize_jump_threads ../../gcc/gcc/tree-vrp.c:9856 0xb856a1 execute_vrp ../../gcc/gcc/tree-vrp.c:10010 0xb856a1 execute ../../gcc/gcc/tree-vrp.c:10073 Please submit a full bug report,
Thanks for the test case. Reproduced and looking at it. Teresa
My new code is exposing an upstream profile count insanity that is being introduced by the copyrename2 phase. The new freqs_to_counts_path routine is invoked only when we don't have profile info, and in this case main() is in mozilla-xremote-client.ii which does not have a gcda file. So the profile status for the fn != PROFILE_READ. Before copyrename2, all the counts in main() are 0, and everything looks fine. But coming out of copyrename2, some of the blocks and edges have a count == 1. So my assert in freqs_to_counts_path that expects the edges to all have 0 weight is firing. The two approaches I could take are to either skip freqs_to_counts if there are actually non-zero counts or simply remove the assert with a comment about upstream insanities. I am probably going to do the latter, because the former will result in really insane frequencies coming out of jump threading (the updates are based on counts, which in this case are bogus coming in). It would be good to figure out why copyrename2 is introducing non-zero counts, but presumably there is some kind of profile update that has an off-by-one error? I don't see any count manipulation within tree-ssa-copyrename.c itself.
Author: tejohnson Date: Thu Oct 2 20:30:11 2014 New Revision: 215822 URL: https://gcc.gnu.org/viewcvs?rev=215822&root=gcc&view=rev Log: 2014-10-01 Teresa Johnson <tejohnson@google.com> PR middle-end/63422 * tree-ssa-threadupdate.c (freqs_to_counts_path): Remove asserts to handle incoming insanities. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
fixed in trunk