r249892 PASS r249961 (?) FAIL / sadly, I rm this version from HDD & cant double-check r249982 FAIL $ cat x.i __attribute__((__cold__)) int a(); inline int b() { a(); } int c() { b(); } $ /usr/local/gcc_current/bin/gcc -fpreprocessed -O -c x.i during GIMPLE pass: profile_estimate x.i: In function ‘c’: x.i:3:1: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 int c() { b(); } ^~~ 0x69298d profile_probability::to_reg_br_prob_base() const /home/dimhen/src/gcc_current/gcc/profile-count.h:189 0x69298d estimate_bb_frequencies(bool) /home/dimhen/src/gcc_current/gcc/predict.c:3559 0xdb373f tree_estimate_probability(bool) /home/dimhen/src/gcc_current/gcc/predict.c:2828 0xdb3a93 execute /home/dimhen/src/gcc_current/gcc/predict.c:3701 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ /usr/local/gcc_current/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc_current/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-pc-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic Thread model: posix gcc version 8.0.0 20170705 (experimental) [trunk revision 249982] (GCC)
r299904 PASS r299023 FAIL ~/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-checking=yes --disable-multilib --enable-languages=c,c++
oh, sorry r299923 FAIL
r249904 PASS r249907 FAIL r250073 FAIL sounds like r249907 | hubicka | 2017-07-03 15:42:07 +0300 (Mon, 03 Jul 2017) | 7 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/profile-count.h M /trunk/gcc/tree-cfg.c M /trunk/gcc/tree-cfgcleanup.c * tree-cfgcleanup.c (want_merge_blocks_p): New function. (cleanup_tree_cfg_bb): Use it. * profile-count.h (profile_count::of_for_merging, profile_count::merge): New functions. * tree-cfg.c (gimple_merge_blocks): Use profile_count::merge.
This bug seems to cause the current Linux kernel 4.12 to fail to compile.
*** Bug 81390 has been marked as a duplicate of this bug. ***
Also happens when compiling the Boost testsuite.
Also see https://gcc.gnu.org/ml/gcc-regression/2017-07/msg00144.html
Reduced Boost testcase: struct A; struct B { typedef A *type; }; struct C { B::type operator->(); }; struct D { struct F { F(void(void *), F *, void()); }; template <typename FunT> struct J : F { FunT m_Function; J(FunT) : F(m_fn1, 0, 0) {} static void m_fn1(void *) { static_cast<J *>(0)->m_Function(); } }; F *m_pImpl; template <typename FunT> D(FunT p1) : m_pImpl(new J<FunT>(p1)) {} }; struct A { void m_fn2(D); }; struct G { void operator()() { throw; } }; struct H { void operator()() try { G()(); } catch (int) { } }; struct I { void operator()() { H()(); } }; void fn1() { I a; C b; b->m_fn2(a); }
Fixed by r250310.
I am not so sure this one is fixed. I have this code: __attribute__((__cold__)) a(); b() { a(); } c() { b(); if (d()) e(); } derived from Linux kernel and it does this with revision 250361: during GIMPLE pass: profile_estimate bug368.c: In function ‘c’: bug368.c:7:1: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 } ^ 0xb58ed1 profile_probability::to_reg_br_prob_base() const ../../trunk/gcc/profile-count.h:189 0xb58ed1 estimate_bb_frequencies(bool) ../../trunk/gcc/predict.c:3568 0xb5cce4 tree_estimate_probability(bool) ../../trunk/gcc/predict.c:2825 0xb5d193 execute ../../trunk/gcc/predict.c:3710 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
(In reply to David Binderman from comment #10) > I have this code: Thanks (note that other attached snippets were fixed by r250310).
Created attachment 41813 [details] Too simple patch for last issue (In reply to David Binderman from comment #10) > I have this code: > ... > derived from Linux kernel and it does this with revision 250361: This happens because count for basic block which calls b() is 0 after early_inline. This prevents probablity assignment in combine_predictions_for_bb: if (!bb->count.initialized_p () && !dry_run) { first->probability = profile_probability::from_reg_br_prob_base (combined_probability); second->probability = first->probability.invert (); } Later this ICEs in estimate_bb_frequencies because it assumes probability is set: if (!bb->count.initialized_p () && !dry_run) { first->probability = profile_probability::from_reg_br_prob_base (combined_probability); second->probability = first->probability.invert (); } Here's a simple fix but it looks more like a hack.
This bug stops the linux kernel compiling and it seems that 7.2 is about to be shipped. Any chance of a fix going into 7.2, or is it best to wait for 7.2.1 ?
(In reply to David Binderman from comment #13) > This bug stops the linux kernel compiling and it seems that 7.2 is > about to be shipped. > > Any chance of a fix going into 7.2, or is it best to wait for 7.2.1 ? ??? This is a 8 only regression. It has nothing to do with 7.2.
>This is a 8 only regression. It has nothing to do with 7.2. Curiouser and curiouser. Richard Biener has just posted that 7.2-rc1 has been created from revision 250819. The small chunk of code I posted AFAIK goes wrong with revisions 250718, 250725, 250757, 250813, 250841. I am no expert in svn, but if 250813 and 250841 demonstrate the fault, then AFAIK something derived from 250819 should also show the fault. Unless you know different.
Not all revisions exist in all branches. Check out the code from http://gcc.gnu.org/svn/gcc/branches/gcc-7-branch to see if the problem exists there. From what I can see from this discussion it will not.
(In reply to Bill Schmidt from comment #16) > Check out the code from http://gcc.gnu.org/svn/gcc/branches/gcc-7-branch to > see if the problem exists there. From what I can see from this discussion > it will not. I confirm I see no problem for the little piece of code with gcc-7 branch. Full linux kernel build with gcc-7 branch in progress. I think I need to understand svn branches and how they relate to revision numbers better. I'll do some reading.
Any prospect of getting this fixed? I haven't been able to build Linux for ~a month now because of this.
(In reply to Markus Trippelsdorf from comment #8) > Reduced Boost testcase: > > struct A; > struct B { > typedef A *type; > }; > struct C { > B::type operator->(); > }; > struct D { > struct F { > F(void(void *), F *, void()); > }; > template <typename FunT> struct J : F { > FunT m_Function; > J(FunT) : F(m_fn1, 0, 0) {} > static void m_fn1(void *) { static_cast<J *>(0)->m_Function(); } > }; > F *m_pImpl; > template <typename FunT> D(FunT p1) : m_pImpl(new J<FunT>(p1)) {} > }; > struct A { > void m_fn2(D); > }; > struct G { > void operator()() { throw; } > }; > struct H { > void operator()() try { G()(); } catch (int) { > } > }; > struct I { > void operator()() { H()(); } > }; > void fn1() { > I a; > C b; > b->m_fn2(a); > } I'm testing patch for this PR. Markus what options are needed to spot ICE with this test-case? Can't reproduce it.
(In reply to Martin Liška from comment #19) > (In reply to Markus Trippelsdorf from comment #8) > > Reduced Boost testcase: > I'm testing patch for this PR. Markus what options are needed to spot ICE > with this test-case? Can't reproduce it. It was fixed by r250310. Only the comment 10 testcase still ICEs.
(In reply to Markus Trippelsdorf from comment #20) > (In reply to Martin Liška from comment #19) > > (In reply to Markus Trippelsdorf from comment #8) > > > Reduced Boost testcase: > > I'm testing patch for this PR. Markus what options are needed to spot ICE > > with this test-case? Can't reproduce it. > > It was fixed by r250310. Only the comment 10 testcase still ICEs. Good, thanks.
Created attachment 41976 [details] Patch candidate So I believe that problem is hidden in determine_unlikely_bbs where we set bb->count = profile_count::zero () for: b () { <bb 2> [0.00%] [count: INV]: a (); return; } I think it's not correct and we should set profile_count::guessed_zero (). Similarly in similar situations in the function. Second problem is at the end of function where we guard wrongly count assignment with dump_file presence. That should be also fixed in the patch. I was able to bootstrap, but ./gcc/testsuite/gcc.dg/compare2.c test-case fails not. Can you please Honza take a look?
determine_unlikely_bbs is intended to propagate known to be cold bbs (profile_count::zero) rather than guessed_zero so it seems to do the job correctly here, because we decide to trust the cold attribute (I am still undecided if we don't want to invent unlikely attribute for that). I will take a look why this leads to ICE on propagating frequencies.
I confirm this bug prevents building the Linux kernel 4.12 with gcc trunk 251201. gcc 7.2 seems to build the kernel just fine.
Also getting this on linux kernel 4.13 release on gcc master branch but not gcc-7: There are at least two locations that generate this backtrace. gcc -O1 -c -o drivers/scsi/mpt3sas/.tmp_mpt3sas_scsih.o ./mpt3sas_scsih.i during GIMPLE pass: profile_estimate drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function ‘mpt3sas_scsih_issue_tm’: drivers/scsi/mpt3sas/mpt3sas_scsih.c:9455:1: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 module_exit(_mpt3sas_exit); ^~~~~~ 0x1085d55f profile_probability::to_reg_br_prob_base() const ../../gcc/profile-count.h:189 0x1085d55f estimate_bb_frequencies(bool) ../../gcc/predict.c:3570 0x10861123 tree_estimate_probability(bool) ../../gcc/predict.c:2827 0x1086165f execute ../../gcc/predict.c:3712 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Simplest ICE generation is -O1. -O0 gets to code errors.
Sorry for the inconvenience, I'll work on that with Honza right after Cauldron this weekend.
reduced test case, quite similar however just to be sure: int a, b; __attribute__((__cold__)) fn1(); __attribute__((always_inline)) fn2() { fn1(); } fn3() { fn2(); if (b) a = 0; }
*** Bug 82238 has been marked as a duplicate of this bug. ***
(In reply to Martin Liška from comment #26) > Sorry for the inconvenience, I'll work on that with Honza right after > Cauldron this weekend. any progress on this?
Still failing for me. $ toolchain/bin/gcc --version gcc (GCC) 8.0.0 20171008 (experimental) (code from comment 27) $ toolchain/bin/gcc -O1 -c /tmp/x.c ... during GIMPLE pass: profile_estimate /tmp/x.c: In function ‘fn3’: /tmp/x.c:9:1: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 } ^ 0x657bef profile_probability::to_reg_br_prob_base() const ../../gcc/profile-count.h:189 0x657bef estimate_bb_frequencies(bool) ../../gcc/predict.c:3570 0xc64eaa tree_estimate_probability(bool) ../../gcc/predict.c:2827 0xc64f83 execute ../../gcc/predict.c:3718
*** Bug 82500 has been marked as a duplicate of this bug. ***
Seems to be fixed now.
Works for me. $ toolchain/bin/gcc -O1 -Wno-attributes -Wno-implicit-int -c /tmp/x.c $ toolchain/bin/gcc --version gcc (GCC) 8.0.0 20171024 (experimental) Thanks Markus, Martin, Honza.
Fixed.