aaron.ballman added a comment. In D124866#3497439 <https://reviews.llvm.org/D124866#3497439>, @tra wrote:
>> CUDA/HIP do not have language spec. > > Well. It's not completely true. CUDA programming guide does serve as the > de-facto spec for CUDA. It's far from perfect, but it does mention > `__noinline__` and `__forceinline__` as function qualifiers: > https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#noinline-and-forceinline Thank you, that's the magic words I was hoping for -- because they're described as function qualifiers, I think it's justifiable to add them as a keyword implementation in Clang and not worry about stepping on the toes of the CUDA spec (it's adhering to what the current spec requires). Should we do `__forceinline__` at the same time so that there's consistency? ================ Comment at: clang/lib/Parse/ParseDecl.cpp:902 + while (Tok.is(tok::kw___noinline__)) { + IdentifierInfo *AttrName = Tok.getIdentifierInfo(); + SourceLocation AttrNameLoc = ConsumeToken(); ---------------- yaxunl wrote: > aaron.ballman wrote: > > I think we should we be issuing a pedantic "this is a clang extension" > > warning here, WDYT? > will do I'm questioning whether my advice here was good or not -- now that I see the CUDA spec already calls these function qualifiers... it's debatable whether this is a Clang extension or just the way in which Clang implements the CUDA function qualifiers. @tra -- do you have opinions? I'm sort of leaning towards dropping the extension warning, but the only reason I can think of for keeping it is if Clang is the only CUDA compiler that doesn't require you to include a header before using the function qualifiers. If that's the case, there is a portability concern. 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
