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