yaxunl marked 4 inline comments as done. yaxunl added inline comments.
================ Comment at: clang/include/clang/Basic/Attr.td:1778-1779 def NoInline : DeclOrStmtAttr { - let Spellings = [GCC<"noinline">, CXX11<"clang", "noinline">, + let Spellings = [Keyword<"__noinline__">, GCC<"noinline">, CXX11<"clang", "noinline">, C2x<"clang", "noinline">, Declspec<"noinline">]; let Accessors = [Accessor<"isClangNoInline", [CXX11<"clang", "noinline">, ---------------- aaron.ballman wrote: > will do ================ Comment at: clang/include/clang/Basic/Features.def:274 +// CUDA/HIP Features +FEATURE(cuda_noinline_keyword, true) + ---------------- aaron.ballman wrote: > Do the CUDA or HIP specs define `__noinline__` as a keyword specifically? If > not, this isn't a `FEATURE`, it's an `EXTENSION` because it's specific to > Clang, not the language standard. CUDA/HIP do not have language spec. In their programming guide, they do not define `__noinline__` as a keyword. Will make it an extension. ================ Comment at: clang/lib/Parse/ParseDecl.cpp:902 + while (Tok.is(tok::kw___noinline__)) { + IdentifierInfo *AttrName = Tok.getIdentifierInfo(); + SourceLocation AttrNameLoc = ConsumeToken(); ---------------- aaron.ballman wrote: > I think we should we be issuing a pedantic "this is a clang extension" > warning here, WDYT? will do ================ Comment at: clang/test/SemaCUDA/noinline.cu:8 +__attribute__((noinline)) void fun2() { } +__attribute__((__noinline__)) void fun3() { } ---------------- aaron.ballman wrote: > I think there should also be a test like: > ``` > [[gnu::__noinline__]] void fun4() {} > ``` > to verify that the double square bracket syntax also correctly handles this > being a keyword now (I expect the test to pass). will do CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124866/new/ https://reviews.llvm.org/D124866 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits