From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15322 invoked by alias); 14 Aug 2014 14:32:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 15287 invoked by uid 89); 14 Aug 2014 14:32:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f45.google.com Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 14 Aug 2014 14:31:59 +0000 Received: by mail-wg0-f45.google.com with SMTP id x12so1149650wgg.4 for ; Thu, 14 Aug 2014 07:31:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.221.74 with SMTP id qc10mr12433456wjc.39.1408026715546; Thu, 14 Aug 2014 07:31:55 -0700 (PDT) Received: by 10.194.20.69 with HTTP; Thu, 14 Aug 2014 07:31:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Aug 2014 14:32:00 -0000 Message-ID: Subject: Re: [PATCH, PR61776] verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate From: Richard Biener To: Wei Mi Cc: GCC Patches , Jan Hubicka , David Li , Martin Jambor Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg01476.txt.bz2 On Mon, Jul 28, 2014 at 8:08 AM, Wei Mi wrote: >> But fact is that it is _not_ necessary to split the block because there >> are no outgoing abnormal edges from it. >> >> The verifier failure is an artifact from using the same predicates during >> CFG building and CFG verifying (usually ok, but for this particular >> case it leads to this issue). >> >> So I don't think your patch is the proper way to address this issue >> (while it certainly works). >> >> Instead whether a call can make abnormal gotos should be recorded >> per-call and stored on the gimple-call. Martin - this is exactly >> one of the cases your patch would address? >> > > Thanks for the comment and thanks to Martin's patch. I try the patch. > It works well to address both pr60449 and pr61776 after some > extension. One extension is to replace GF_CALL_LEAF attribute using > GF_CALL_NO_ABNORMAL_GOTO. That is because not only dropping "leaf" > attribute in lto symbol merge could introduce the control flow > verification problem in pr60449, dropping "const/pure" attributes > could introduce the same problem too. It is unnecessary to introduce > per-call attributes for all these three: ECF_LEAF/ECF_CONST/ECF_PURE, > so GF_CALL_NO_ABNORMAL_GOTO is introduced to indicate that a call stmt > has no abnormal goto. > > GF_CALL_NO_ABNORMAL_GOTO will be set according to gimple_call_flags() > once gimple call stmt is created, then updated in execute_fixup_cfg > and cleanup_tree_cfg. > > I posted the extended patch here. I didn't add the noreturn part in > because it has no direct impact on pr60449 and pr61776. I can help > Martin to test and post that part as an independent patch later. > > bootstrap and regression pass on x86_64-linux-gnu. Is it ok? +static void +update_no_abnormal_goto_attr (basic_block bb) +{ + gimple_stmt_iterator gsi; + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi)) + { it should be enough to check these on last stmts of a basic block, no? That you call update_no_abnormal_goto_attr from two places before cleanup_tree_cfg_bb suggests you may want to perform this change in cleanup_control_flow_bb which already looks at the last stmt only? Btw, I originally had this whole idea of moving flags to the gimple stmt level because of the "interesting" way we handle the noreturn attribute (calls to noreturn functions also end basic-blocks). Thus would it be possible to turn all these into a single flag, GF_CALL_CTRL_ALTERING? That is, cover everything that is_ctrl_altering_stmt covers? I suggest we initialize it at CFG build time and only ever clear it later. Sorry for not thinking about this earlier (and for the slow review). Thanks, Richard. > Thanks, > Wei.