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.
