According to the output the ICE is in the newly generated function (_GLOBAL__N_bar) which is the one that remains. Further more the compilation continues until the expand pass (outline.c.180r.expand), where the error happens. The original function (bar) is last seen in outline.c.056i.comdats. I am a little confused by that, since comdats does not change anything. But maybe there is no connection between the violated assertion and the vanishing function.
On 03 Jun 2014, at 15:14, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber > <benedikt.hu...@theobroma-systems.com> wrote: >> >> I have not found out why the assertion is violated, yet. >> However I noticed that the original function disappears somehow between >> the passes pass_ipa_comdats and pass_fixup_cfg. >> By that I mean that the function appears from the dump files. >> These passes run several passes after the outlining pass. >> Between the outlining pass and pass_ipa_comdats both functions >> (the generated and the original with the call to the generated) are printed. >> I do not know whether this has anything to do with the assertion but it >> seems strange. >> Do you have any guess why this happens? > > It probably vanishes because this is the function you ICE for? > >> Thank you, >> Benedikt >> >> On 28 May 2014, at 15:50, Richard Biener <richard.guent...@gmail.com> wrote: >> >>> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber >>> <benedikt.hu...@theobroma-systems.com> wrote: >>>> I ported the pass to the fsf trunk. It is built with —enable-checking. >>>> The patch applied with no changes and also the behaviour is the same. >>>> So I probably mess up the cfg somehow. >>>> Can you suggest any strategy for finding the problem that I could use? >>>> >>>> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details >>>> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass >>>> -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c >>>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar': >>>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in >>>> purge_dead_edges, at cfgrtl.c:3179 >>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l) >>>> ^ >>>> 0x681195 purge_dead_edges(basic_block_def*) >>>> ../../src/gcc/cfgrtl.c:3179 >>>> 0xe64d8a find_bb_boundaries >>>> ../../src/gcc/cfgbuild.c:522 >>>> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*) >>>> ../../src/gcc/cfgbuild.c:604 >>>> 0x66e689 execute >>>> ../../src/gcc/cfgexpand.c:5905 >>>> Please submit a full bug report, >>>> with preprocessed source if appropriate. >>>> Please include the complete backtrace with any bug report. >>>> See <http://gcc.gnu.org/bugs.html> for instructions. >>> >>> Well, look at the CFG and see if it makes sense and why it expects >>> a single successor and why there is none. Basically, work back >>> from the ICE ... >>> >>> Richard. >>> >>>> Best regards, >>>> Benedikt >>>> >>>> On 27 May 2014, at 17:35, Benedikt Huber >>>> <benedikt.hu...@theobroma-systems.com> wrote: >>>> >>>>> >>>>> On 27 May 2014, at 17:25, Richard Biener <richard.guent...@gmail.com> >>>>> wrote: >>>>> >>>>>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber >>>>>> <benedikt.hu...@theobroma-systems.com> wrote: >>>>>>> >>>>>>> On 27 May 2014, at 17:09, Richard Biener <richard.guent...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber >>>>>>>> <benedikt.hu...@theobroma-systems.com> wrote: >>>>>>>>> (Sorry for the duplicate.) >>>>>>>>> >>>>>>>>> I managed to pass the needed parameters to the generated function. >>>>>>>>> However I cannot pin down the reason why the compilation fails. >>>>>>>>> It seems that the cfg is somehow broken, but I cannot tell how. >>>>>>>>> Do you have any debugging hints? >>>>>>>>> >>>>>>>>> As far as I can tell, the cfg is changed during the generation of the >>>>>>>>> preheader >>>>>>>>> (I do this to find the entry block easily.) >>>>>>>>> and in the function move_sese_region_to_fn. >>>>>>>>> >>>>>>>>> I noticed that after pass 058t.copyrename2 the original function bar >>>>>>>>> disappears >>>>>>>>> and the new function is replaced by _GLOBAL__N_bar.constprop, could >>>>>>>>> this have >>>>>>>>> anything to do with the problem? >>>>>>>> >>>>>>>> Unlikely. You can disable that by using -fno-ipa-cp. >>>>>>>> >>>>>>>>> The pass runs just after the construction of cfg, outline.c.011t.cfg. >>>>>>>>> >>>>>>>>> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src >>>>>>>>> -c -fdump-tree-all-details -fdump-ipa-all-details >>>>>>>>> -fdump-rtl-all-details -funinline-innermost-loops -Wall -Wextra >>>>>>>>> /home/bhuber/sandbox/try/outline.c >>>>>>>>> /home/bhuber/sandbox/try/outline.c: In function >>>>>>>>> '_GLOBAL__N_bar.constprop': >>>>>>>>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in >>>>>>>>> purge_dead_edges, at cfgrtl.c:3183 >>>>>>>> >>>>>>>> the line doesn't match anything that would ICE on current trunk, but I >>>>>>>> suppose >>>>>>>> it's the single_succ_p assert that triggers? >>>>>>> Yes, that is right, it is >>>>>>> >>>>>>> gcc_assert (single_succ_p (bb)); >>>>>>> >>>>>>>> >>>>>>>> Either you really got until RTL generation or somehow cfgrtl cfg hooks >>>>>>>> are >>>>>>>> still active while you are working in your pass. >>>>>>> >>>>>>> The pass that fails, according to the dump files is >>>>>>> outline.c.174r.expand >>>>>>> So it already tries to generate RTL. >>>>>>> My problem is that there are so many passes in >>>>>>> between, that I do not know where to start looking. >>>>>>> Any idea? >>>>>> >>>>>> What code-base are you developing on? Do you build with checking >>>>>> enabled (--enable-checking, the default on trunk but not on release >>>>>> branches). >>>>> >>>>> It is a linaro branch, but I am going to port the pass to the fsf trunk >>>>> and see >>>>> whether the behaviour changes. >>>>> >>>>> Best regards, >>>>> Benedikt >>>>> >>>>>> >>>>>> Richard. >>>>>> >>>>>>>> >>>>>>>> Richard. >>>>>>>> >>>>>>>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l) >>>>>>>>> ^ >>>>>>>>> 0x67e7c4 purge_dead_edges(basic_block_def*) >>>>>>>>> ../../src/gcc/cfgrtl.c:3183 >>>>>>>>> 0xe5a0d6 find_bb_boundaries >>>>>>>>> ../../src/gcc/cfgbuild.c:522 >>>>>>>>> 0xe5a0d6 find_many_sub_basic_blocks(simple_bitmap_def*) >>>>>>>>> ../../src/gcc/cfgbuild.c:604 >>>>>>>>> 0x66c0f5 execute >>>>>>>>> ../../src/gcc/cfgexpand.c:5873 >>>>>>>>> Please submit a full bug report, >>>>>>>>> with preprocessed source if appropriate. >>>>>>>>> Please include the complete backtrace with any bug report. >>>>>>>>> See <http://gcc.gnu.org/bugs.html> for instructions. >>>>>>>>> >>>>>>>>> I attach the transformation pass and the small example program. >>>>>>>>> >>>>>>>>> Thank you again for the help, >>>>>>>>> Benedikt >>>>>>>>> >>>>>>>>> P.s. I am aware that this transformation is not safe in general, >>>>>>>>> however in this case it should work. >>>>> >>>> >>
