[cfe-dev] [RFC] C++17 hardware constructive / destructive interference size

[John McCall via cfe-dev]

> On May 29, 2018, at 4:39 PM, JF Bastien via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> On May 25, 2018, at 3:12 PM, James Y Knight <jyknight at google.com <mailto:jyknight at google.com>> wrote:
>> 
>> 
>> 
>> On Fri, May 25, 2018 at 5:30 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>> 
>> 
>>> On May 25, 2018, at 2:23 PM, James Y Knight <jyknight at google.com <mailto:jyknight at google.com>> wrote:
>>> 
>>> My own employer doesn't make ABI stability promises for that code, and thus is fine with changing the value anytime it feels like. That's not a generically viable strategy for a value provided by the standard library.
>>> 
>>> Additionally, before I sent that email, I looked at a number of the uses, and it appeared as though a great many could be easily modified to use a runtime-determined alignment.
>> 
>> That would be useful feedback on the paper… prior to it getting into C++17. The committee’s POV voting the paper in was that having a constexpr value was something we wanted, and so that’s what we have. At this point in time I’d like to focus on implementing C++17 as it is, and / or filing DRs as required.
>> 
>> Sure. I'm not on the committee. Even if I was, I certainly don't know that I would have identified the problem...
>> 
>> But now that it has been identified, there's a choice of what to do. And not implementing the function (and presumably filing a DR saying so) is seeming like a pretty reasonable option.
> 
> 
> The committee discussed ABI issues (Jacksonville 2016) and decided that they’d rather have them than have a proliferation of #define SOMETHING 64. That discussion occurred with Google folks in the room, it might be higher bandwidth to consult with them? The notes are unfortunately quite sparse for that discussion.

If the committee is okay with the possibility of otherwise-ABI-compatible target differences causing ODR violations, that seems like something they should be very explicit about.

> The libc++ community shouldn't decline to implement a feature without bringing concrete feedback to the committee. Without such feedback, I’d like to move forward with an implementation plan, because we should offer full C++17 support regardless of our distaste for specific features.

As a general goal I agree, but I think we have to acknowledge that sometimes changes will move through the committee process and only later be recognized as problematic.  I don't think this rises to the level of "export template"-style intransigence, but still, if we're not sure how to implement what the committee has standardized, we should get guidance from the committee instead of implementing *something* just to tick a checkbox.

Separate question that I don't think has been covered here: who actually owns the values of these constants?  Is it really up to the C++ standard library, or is this really part of the platform ABI that's just being exposed in a special way?  That is, do different C++ standard libraries on the same target have a responsibility to ensure that they use the same value?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180529/576fde91/attachment.html>