[PATCH] D121497: Lex: add support for `{,u}i128` Microsoft extension

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 16 06:57:06 PDT 2022


aaron.ballman added reviewers: urnathan, iains, ChuanqiXu.
aaron.ballman added a comment.

In D121497#3383910 <https://reviews.llvm.org/D121497#3383910>, @compnerd wrote:

> This was something that I was hitting an issue with.

Does cl hit the same issue when building a module that includes intsafe.h?

> In particular, it was a module build for a module which pulled in intsafe.h.  Now, given that it is a preprocessor macro, it would stand to reason that it will normally be dropped and thus won't matter if the frontend doesn't actually support a 128-bit type.  However, with a module, we would attempt to process the expression. I do admit it is on a slightly more tenuous ground as Microsoft may somehow do something different.

I am by no means a modules expert (so I'm adding folks to the review who are for their input), but I guess I am naively surprised that a module build would evaluate the macro's expansion list when no code in the module actually expands the macro. So I can't tell whether the issue is that Clang is emitting an error when it shouldn't, or whether cl.exe is failing to emit an error when it should, or something else. But it seems wrong to me to add a Microsoft extension that cl.exe doesn't actually support; that's likely to lead to a fair amount of user confusion. But it could also lead to ABI issues later if Microsoft did decide to support this type but using slightly different calling conventions than Clang uses.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121497/new/

https://reviews.llvm.org/D121497



More information about the cfe-commits mailing list