[PATCH] c++: implement C++17 hardware interference size

Jason Merrill jason@redhat.com
Sat Jul 17 21:37:33 GMT 2021


On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz <m.kretz@gsi.de> wrote:

> On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
> > On Sat, 17 Jul 2021, 09:15 Matthias Kretz, <m.kretz@gsi.de> 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


More information about the Libstdc++ mailing list