From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id CB364385DC08; Mon, 19 Jul 2021 09:41:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB364385DC08 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 70CA26D; Mon, 19 Jul 2021 02:41:21 -0700 (PDT) Received: from [10.57.6.202] (unknown [10.57.6.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3249A3F73D; Mon, 19 Jul 2021 02:41:20 -0700 (PDT) Subject: Re: [PATCH] c++: implement C++17 hardware interference size To: Jason Merrill , Matthias Kretz Cc: "Richard Earnshaw (lists)" , Jonathan Wakely , GNU C Library , libstdc++ , gcc-patches List , Jonathan Wakely References: <20210716023656.670004-1-jason@redhat.com> <3179041.TO5rdG3zkT@excalibur> <90365047.B8guWdUDZo@excalibur> From: Richard Earnshaw Message-ID: Date: Mon, 19 Jul 2021 10:41:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3491.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 09:41:23 -0000 On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote: > On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote: > >> On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote: >>> On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote: >>>> If somebody writes a library with `keep_apart` in the public API/ABI >> then >>>> you're right. >>> >>> Yes, it's fine if those constants don't affect anything across module >>> boundaries. >> >> I believe a significant fraction of hardware interference size usage will >> be >> internal. >> > > I would hope for this to be the vast majority of usage. I want the warning > to discourage people from using the interference size variables in the > public API of a library. > > >>>> The developer who wants his code to be included in a distro should care >>>> about >>>> binary distribution. If his code has an ABI issue, that's a bug he >> needs >>>> to >>>> fix. It's not the fault of the packager. >>> >>> Yes but in practice it's the packagers who have to deal with the bug >>> reports, analyze the problem, and often fix the bug too. It might not be >>> the packager's fault but it's often their problem >> >> I can imagine. But I don't think requiring users to specify the value >> according to what -mtune suggests will improve things. Users will write a >> configure/cmake/... macro to parse the value -mtune prints and pass that >> on >> the command line (we'll soon find this solution on SO 😜). I.e. things are >> likely to be even more broken. > > > Simpler would be a flag to say "set them based on -mtune", e.g. > -finterference-tuning or --param destructive-intereference-size=tuning. > That would be just as easy to write as -Wno-interference-size. > > Jason > Please be very careful about an option name like that. The x86 meaning and interpretation of -mtune is subtly different to that of Arm and AArch64 and possibly other targets as well. Also, should the behaviour of a compiler configured with --with-cpu=foo be handled differently to a command-line option that sets foo explicitly? In the back-end I'm not sure we can really tell the difference. R.