From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99045 invoked by alias); 29 Jun 2017 16:05:33 -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 98936 invoked by uid 89); 29 Jun 2017 16:05:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*x:version, H*UA:version, H*m:20170629, H*UA:6.0 X-HELO: shards.monkeyblade.net Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net) (184.105.139.130) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 16:05:30 +0000 Received: from localhost (unknown [38.140.131.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id AFAFE1247EBB2; Thu, 29 Jun 2017 08:23:40 -0700 (PDT) Date: Thu, 29 Jun 2017 16:05:00 -0000 Message-Id: <20170629.120524.1722371272567684822.davem@davemloft.net> To: cederman@gaisler.com Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, sebastian.huber@embedded-brains.de, daniel@gaisler.com Subject: Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata From: David Miller In-Reply-To: <4c5c96e9-ea63-f6f7-1066-2a907db7c393@gaisler.com> References: <20170627085530.12596-1-cederman@gaisler.com> <9253669.0heIyC41JS@polaris> <4c5c96e9-ea63-f6f7-1066-2a907db7c393@gaisler.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg02305.txt.bz2 From: Daniel Cederman Date: Thu, 29 Jun 2017 17:15:43 +0200 >> I'm not thrilled with this, it's undocumented, the other workaround >> don't have >> it and I don't think that we really need it. > > The B2BST errata workaround requires more changes to assembler > routines commonly used by operating systems, such as for example > register window handling, than what the UT699 workaround needed. It > would be nice to have a way to only enable these modification when the > -mfix- flag is used. The alternative would be to provide a define > directly on the compiler command line in conjunction with -mfix > flag. But if more changes are required later on it would be good to > have the define more closely tied to the flag to minimize the number > of changes to Makefiles and etc. Personally, I have never seen compiler based CPP defines as ever being useful for tailoring OS assembler code. Ever. In most cases you will want to support several families of CPUs and therefore sort out the individual cpu support assembler routines internally in the kernel sources.