This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How can I generate a new function at compile time?

On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
<benedikt.huber@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.guenther@gmail.com> wrote:
>
>> On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
>> <benedikt.huber@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.guenther@gmail.com> wrote:
>>>
>>>> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
>>>> <benedikt.huber@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.huber@theobroma-systems.com> wrote:
>>>>>
>>>>>>
>>>>>> On 27 May 2014, at 17:25, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>
>>>>>>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>>>>>> <benedikt.huber@theobroma-systems.com> wrote:
>>>>>>>>
>>>>>>>> On 27 May 2014, at 17:09, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>>>>>>>>> <benedikt.huber@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.
>>>>>>
>>>>>
>>>
>
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]