On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz <m.kr...@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.kr...@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
