From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3AC853942020; Wed, 18 Mar 2020 18:31:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3AC853942020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1584556300; bh=GSosj2kM2o6eTjVq3Lfls1QjAWTM2hBrQ2a5UGRy+Qc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WzuGKHmXC/bl0WMbfg79qQjuEPemIY645ldToqkkNuOeGmtIX7qeen7AevcRNdE74 tJP7WUKHTJ4oURUcSpKn4rsTpWoffcmIVgbSnZWFIYaJfyaYD/pjCTI5XP9YJ7Swh1 85KmQiristWXNS+myUDyveoZzGS3WdhnjX/XEsxw= From: "foom at fuhm dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size Date: Wed, 18 Mar 2020 18:31:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: foom at fuhm dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 18:31:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88466 James Y Knight changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |foom at fuhm dot net --- Comment #7 from James Y Knight --- FWIW, the discussion in Clang about this is still ongoing, and the functions remain unimplemented there. I personally remain of the opinion that it would be ideal to leave these permanently unimplemented, despite that the standards committee decided to = keep them in the standard even after objections were raised. My second-favorite implementation after "unimplemented", would be to just return constant values of 64 and 128 universally, regardless of architectur= e. (If you cannot return an actually-correct answer, and decided that you need= to return something, you might as well just do something really easy and, _shr= ug_, oh well.). Others are arguing for implementing them to return actually valid and corre= ct values that depend on the exact configuration, and marking them as not being abi-stable. Users would then need to be aware that they must not use the constants in ABIs (which means effectively "don't use in a header file"), s= ince the value might change at any time with a compiler upgrade, or with the use= of different command-line flags (e.g. -mcpu/-march). (To return correct values, compiler upgrades must be allowed to change the values if it becomes aware of a new CPU model which changes the largest/smallest-known cacheline sizes that this code could run on. And -mcpu/-march flags similarly ought to change the values by restricting the possible set of CPUs this code might run on.) Any new thoughts from GCC developers?=