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.
