Ah, now I get it. So the reason is that comdats is the last ipa pass that is run.
I continue to look for the problem in purge_dead_edges. Thank you for the explanation. Best regards, Benedikt On 03 Jun 2014, at 16:10, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber > <benedikt.hu...@theobroma-systems.com> wrote: >> >> 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. > > Well, if it ICEs in _GLOBAL__N_bar then compilation stops - passes after IPA > are executed for one function all to the end, so this just means the > original bar > wasn't processed yet. > > Richard. > >> 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. >>>>>>> >>>>>> >>>> >>
