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. >>>> >>> >
