On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote:
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
Please be very careful about an option name like that. The x86 meaning
and interpretation of -mtune is subtly different to that of Arm and
AArch64 and possibly other targets as well.
Also, should the behaviour of a compiler configured with --with-cpu=foo
be handled differently to a command-line option that sets foo
explicitly? In the back-end I'm not sure we can really tell the difference.
R.
