From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31976 invoked by alias); 24 Sep 2018 09:19:52 -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 31965 invoked by uid 89); 24 Sep 2018 09:19:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=justified X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Sep 2018 09:19:50 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 475A281390; Mon, 24 Sep 2018 11:19:48 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TjzhpCmmucG; Mon, 24 Sep 2018 11:19:48 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 277818138E; Mon, 24 Sep 2018 11:19:48 +0200 (CEST) From: Eric Botcazou To: "Richard Earnshaw (lists)" Cc: gcc-patches@gcc.gnu.org Subject: Re: [ARM] Fix ICE during thunk generation with -mlong-calls Date: Mon, 24 Sep 2018 09:26:00 -0000 Message-ID: <4513247.hs9z0gJsOX@polaris> In-Reply-To: References: <1722777.YijAB52ccF@polaris> <1672454.sA1WPEYBBg@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2018-09/txt/msg01324.txt.bz2 > Ah! But that still doesn't explain why you want to skip these passes > when building thunks. They simply don't work because there is no CFG for thunks; I can add a blurb about that. > So is the barrier correct, or isn't it? There's really no two ways > about this. I don't like arbitrary changes that are justified solely on > 'that's what another port does'. The barrier is required by the arm_reorg pass, but it is optional when the pass is not run. I think that we can consider that it is also correct. -- Eric Botcazou