[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 24 11:17:46 PDT 2021
aaron.ballman added inline comments.
================
Comment at: clang/docs/ReleaseNotes.rst:145
+- The mangling of the ``_ExtInt(N)`` datatype has changed in both the Microsoft
+ ABI and Itanium ABI.
----------------
erichkeane wrote:
> Hrm... not a huge fan that this still claims that ``_ExtInt`` is a type(though don't have a better wording), but I'd also probably want to mention that it now matches the new type. Perhaps something like:
>
> The ``_ExtInt(N)`` family of types have been replaced with the C2X standardized version of the feature, ``_BitInt(N)``. Therefore, source that previously used the ``_ExtInt`` types will now be mangled to instead use the ``_BitInt(N)`` spelling in both the Microsoft and Itanium ABIs.
I can go with this.
================
Comment at: clang/include/clang/Basic/TargetInfo.h:581
/// limitation is put into place for ABI reasons.
- virtual bool hasExtIntType() const {
+ /// FIXME: _BitInt is a required type in C23, so there's not much utility in
+ /// asking whether the target supported it or not; I think this should be
----------------
erichkeane wrote:
> erichkeane wrote:
> > Concur on the fixme. I would expect after this lands that an llvm-dev discussion happen to do this alert, and have us remove this pretty quickly (a release or two?)
> To clarify: This should be removed at the beginning of a release-cycle (along with an llvm-dev notice) so that we have as much time as possible in trunk to react/find issues.
We're basically at the beginning of Clang 14 (13 isn't out the door yet), so I am sort of tempted to alert llvm-dev now and remove it as part of this review. However, if people think that's too harsh, I'm happy to wait as well.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D108643/new/
https://reviews.llvm.org/D108643
More information about the cfe-commits
mailing list