On Wed, Mar 18, 2015 at 12:03 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
> On 18-03-15 11:16, Richard Biener wrote:
>>
>> On Fri, Mar 13, 2015 at 4:28 PM, Tom de Vries <tom_devr...@mentor.com>
>> wrote:
>>>
>>> On 13-03-15 13:36, Richard Biener wrote:
>>>>
>>>>
>>>> On Fri, Mar 13, 2015 at 1:07 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>>>>>
>>>>>
>>>>> On Fri, Mar 13, 2015 at 01:04:57PM +0100, Richard Biener wrote:
>>>>>>
>>>>>>
>>>>>> Not really (I don't like -fdump-passes ...), but we need to make sure
>>>>>> that -fdump-passes doesn't crash (because it runs very early and
>>>>>> with cfun == NULL I think)
>>>>>
>>>>>
>>>>>
>>>>> If it runs with cfun == NULL, then supposedly the gates that are
>>>>> dependent
>>>>> on current function should for -fdump-passes purposes also return true
>>>>> if cfun == NULL (well, of course do all the unconditional checks).
>>>>> Though of course, with optimize/target attributes this is harder, as
>>>>> different functions can use different options.
>>>>
>>>>
>>>>
>>>> Yes, one reason why I think -fdump-passes is just broken
>>>> implementation-wise.
>>>>
>>>
>>> Atm fdump-passes doesn't run with cfun == NULL.
>>>
>>>  From pass_manager::dump_passes:
>>> ...
>>>    FOR_EACH_FUNCTION (n)
>>>      if (DECL_STRUCT_FUNCTION (n->decl))
>>>        {
>>>          node = n;
>>>          break;
>>>        }
>>>
>>>    if (!node)
>>>      return;
>>>
>>>    push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>>
>>
>> Um - this now picks a random function which may be one with
>> an optimize or target attribute associated to it.
>>
>
> Indeed.
>
> Attached patch removes that code, and runs the gates with cfun == NULL for
> -fdump-passes. It at least builds, and allows us to compile
> src/gcc/testsuite/gcc.dg/dump-pass.c with -O2 -fdump-passes.
>
> Should I bootstrap and reg-test, or do you see a problem with this approach?

Yeah - it makes the -fdump-passes "hack" more pervasive throughout
the compiler.

I suppose it should instead build & push a "dummy" sturct function.

Well, or simply don't care for it's brokeness.

Richard.

> Thanks,
> - Tom
>
>

Reply via email to