From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59228 invoked by alias); 17 Jan 2017 08:21:50 -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 59181 invoked by uid 89); 17 Jan 2017 08:21:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=questionable, invention, H*MI:sk:2384369, H*f:sk:2384369 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; Tue, 17 Jan 2017 08:21:48 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id ACD80813E9; Tue, 17 Jan 2017 09:21:44 +0100 (CET) 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 sWCIz3R_88Uw; Tue, 17 Jan 2017 09:21:44 +0100 (CET) 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 E117C8139E; Tue, 17 Jan 2017 09:21:43 +0100 (CET) From: Eric Botcazou To: Alan Modra Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool Subject: Re: [ping] 3 aarch64/arm/rs6000 patches Date: Tue, 17 Jan 2017 08:21:00 -0000 Message-ID: <1734584.BCzy5hZgeC@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-53-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170117080053.GJ32333@bubble.grove.modra.org> References: <2384369.JtBCaDPbPu@polaris> <20170117080053.GJ32333@bubble.grove.modra.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2017-01/txt/msg01165.txt.bz2 > The one thing I find questionable about this patch is that it will set > mem_alias_set for the resulting MEMs to the TOC alias set. Is that > correct for memory not in the TOC? I don't understand why the memory would not be in the TOC (but I discovered this TOC business while investigating the issue, nice invention ;-) Or rather I don't understand why this would be a problem with the patch if this was not already the case in the existing code. The main difference between VxWorks and the other ports is that you cannot create TOC entries manually, they are exclusively created by the linker; but that's it, if they are created properly, they work as for the other ports. -- Eric Botcazou