From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-393516-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 72693 invoked by alias); 13 Mar 2015 15:28:29 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 72633 invoked by uid 89); 13 Mar 2015 15:28:28 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: relay1.mentorg.com
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Mar 2015 15:28:27 +0000
Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com)	by relay1.mentorg.com with esmtp 	id 1YWRVf-0003xb-IR from Tom_deVries@mentor.com ; Fri, 13 Mar 2015 08:28:23 -0700
Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Fri, 13 Mar 2015 15:28:22 +0000
Message-ID: <55030211.5060203@mentor.com>
Date: Fri, 13 Mar 2015 15:28:00 -0000
From: Tom de Vries <Tom_deVries@mentor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Richard Biener <richard.guenther@gmail.com>, Jakub Jelinek	<jakub@redhat.com>
CC: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, stage1] Make parloops gate more strict
References: <5502BCA2.2010802@mentor.com>	<CAFiYyc28u76-1Pk14zTKq8jYtpz14eH3eENOQ0Y0pAnfuU2Zmw@mail.gmail.com>	<5502C620.1050202@mentor.com>	<CAFiYyc3ozwh_gfwogg+MwUJUSub7X3n9TeMoxg=PW_SNSP+4pg@mail.gmail.com>	<20150313120756.GC1746@tucnak.redhat.com> <CAFiYyc0zBO3wG17aDsX9GfPELyN5xqJa4NmANiccT=cfGURsDQ@mail.gmail.com>
In-Reply-To: <CAFiYyc0zBO3wG17aDsX9GfPELyN5xqJa4NmANiccT=cfGURsDQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2015-03/txt/msg00756.txt.bz2

On 13-03-15 13:36, Richard Biener wrote:
> On Fri, Mar 13, 2015 at 1:07 PM, Jakub Jelinek <jakub@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));
...

This was discussed here: https://gcc.gnu.org/ml/gcc-patches/2011-06/msg00856.html

Thanks,
- Tom