[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[foom at fuhm dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466

James Y Knight <foom at fuhm dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |foom at fuhm dot net

--- Comment #7 from James Y Knight <foom at fuhm dot net> ---
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 architecture.
(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, _shrug_,
oh well.).


Others are arguing for implementing them to return actually valid and correct
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"), since
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?

[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to James Y Knight from comment #7)
> 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.

I'm inclined to agree.

> My second-favorite implementation after "unimplemented", would be to just
> return constant values of 64 and 128 universally, regardless of
> architecture. (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, _shrug_, oh well.).

Which makes them just verbose ways to spell an integer that might or might not
be right for your target.

> Others are arguing for implementing them to return actually valid and
> correct 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"), since the value might change at any time with a compiler upgrade, or
> with the use of different command-line flags (e.g. -mcpu/-march).

I suppose a warning if you use them in a header might mitigate the dangers a
bit.

> (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?

I'm not aware of anybody planning to work on them.

I continue to think they're broken by design.

[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |12.0
         Resolution|---                         |FIXED

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Implemented in r12-3495