From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.kolabnow.com (mx.kolabnow.com [95.128.36.42]) by sourceware.org (Postfix) with ESMTPS id 8337E3989097; Tue, 20 Jul 2021 18:05:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8337E3989097 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=appliantology.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=appliantology.com Received: from localhost (unknown [127.0.0.1]) by ext-mx-out001.mykolab.com (Postfix) with ESMTP id A95A5B9A; Tue, 20 Jul 2021 20:05:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= message-id:references:in-reply-to:subject:subject:from:from:date :date:content-type:content-type:mime-version:received:received :received; s=dkim20160331; t=1626804333; x=1628618734; bh=YUrRwb +V9RefHYCeKQ+S7JL4BbD1WzbKnSei607AxlQ=; b=Cflv0koX5pH0hpwmLX490V Y9rExIfomYEFKPj7VUjM/IcLQzyEUiUb9drKu+Qb1qJjJcXmeMiOUIIp9WU7H1a1 GNP0XVEU3tgg/v7ZtpMZHRfaNYo02yiYCxKYP3LnysssXRnXsG1U7sid41EnvRE6 0PlGpvAHnFkehLVEpAgdqaKW2ax11wfTiKmAtUysHveZQ48RuRN7RaRgvpq/Figl nrpfKJWEIZqPKzn1N160uxcm9abrlNMMAm4+NA2AQcCrp36FkpG0DRB/KuXVsuFu rUYGkEx9jw2lP/Ucbguh5f2nCjdmpr+WbAFjSGJLf9dk0jHnT6Nd0H297jocnPpz R6YIbZtpbZQ7Je+r92gcxAMuyW2fJfRGbZPZ3vaRwJLReN4FN4IM5aYtZbqxaQsl 5g1PWXD7cuXCjZr1j7gQEdBVKpMACNkmJn6gDVr/RZG+Qk+5Y42NNADGxzoiMcb0 wrrMynUo1yu+6+Q0h9/sUZ7rBBwyKfpJ8HSvmrEjPvluDVN3FLmlv4GjzjDqGFev hIn139lHIi8DZS5mef4i3EMkEnHMnKB+c4g1aR2aVbxe7Q7w4E1NSH2DHbAgPYsr uviYmK8ga6BMFMcvq4tG+Cw78RdEcyYKBhgKQvbkpQ5wolCTNQSVNubY4b5ybs5I XaZvjr8J1QlxpmNT1tUR8= X-Virus-Scanned: amavisd-new at mykolab.com X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out001.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7hOJ2PbgxKk; Tue, 20 Jul 2021 20:05:33 +0200 (CEST) Received: from int-mx003.mykolab.com (unknown [10.9.13.3]) by ext-mx-out001.mykolab.com (Postfix) with ESMTPS id DE7B9A6F; Tue, 20 Jul 2021 20:05:31 +0200 (CEST) Received: from int-subm002.mykolab.com (unknown [10.9.37.2]) by int-mx003.mykolab.com (Postfix) with ESMTPS id 6A79B3EE2; Tue, 20 Jul 2021 20:05:25 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 20 Jul 2021 11:05:23 -0700 From: Thomas Rodgers To: Jonathan Wakely Cc: Matthias Kretz , "Richard Earnshaw (lists)" , GNU C Library , libstdc++ , gcc-patches List Subject: Re: [PATCH] c++: implement C++17 hardware interference size In-Reply-To: References: <20210716023656.670004-1-jason@redhat.com> <2948804.xd1mhZDcFd@excalibur> <3179041.TO5rdG3zkT@excalibur> Message-ID: <8efa1ec53ede3c16bebbd0a464a76c76@appliantology.com> X-Sender: rodgert@appliantology.com X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 20 Jul 2021 18:05:39 -0000 On 2021-07-17 06:32, Jonathan Wakely via Gcc-patches wrote: > On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote: > > On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote: On Fri, 16 > Jul 2021 at 20:26, Matthias Kretz wrote: On Friday, 16 > July 2021 18:54:30 CEST Jonathan Wakely wrote: On Fri, 16 Jul 2021 at > 16:33, Jason Merrill wrote: Adjusting them based on tuning would > certainly simplify a significant > use > case, perhaps the only reasonable use. Cases more concerned with ABI > stability probably shouldn't use them at all. And that would mean not > needing to worry about the impossible task of finding the right values > for > an entire architecture. > But it would be quite a significant change in behaviour if -mtune > started affecting ABI, wouldn't it? For existing code -mtune still doesn't affect ABI. True, because existing code isn't using the constants. > The users who write > > struct keep_apart { > > alignas(std::hardware_destructive_interference_size) std::atomic > cat; > alignas(std::hardware_destructive_interference_size) std::atomic > dog; > > }; > > *want* to have different sizeof(keep_apart) depending on the CPU the code >> is compiled for. I.e. they *ask* for getting their ABI broken. > > Right, but the person who wants that and the person who chooses the > -mtune option might be different people. Yes. But it was the intent of the person who wrote the code that the person compiling the code can change the data layout of keep_apart via -mtune. Of course, if the one compiling doesn't want to choose because the binary needs to work on the widest range of systems, then there's a problem we might want to solve (direction of target_clones?). (Or the developer of the library solves it by providing the ABI for all possible interference_size values.) > A distro might add -mtune=core2 to all package builds by default, not > expecting it to cause ABI changes. Some header in a package in the > distro might start using the constants. Now everybody who includes > that header needs to use the same -mtune option as the distro default. 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. >> That change in the behaviour and expected use of an existing option >> seems scary to me. Even with a warning about using the constants >> (because somebody's just going to use #pragma around their use of the >> constants to disable the warning, and now the ABI impact of -mtune is >> much less obvious). > > There are people who say that linking TUs compiled with different > compiler > flags is UB. In general I think that's correct, but we can make > explicit > exceptions. Up to now -mtune wouldn't lead to UB, AFAIK, though -march > easily > does. So maybe, to keep the status quo, the constants should be tied to > -march > not -mtune? > >> It's much less scary in a world where the code is written and used by >> the same group of people, but for something like a linux distro it >> worries me. > > 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 :-( Apropos of nothing, I can absolutely see the use of this creeping into Boost at some point.