aaron.ballman added a comment.
In D124866#3501641 <https://reviews.llvm.org/D124866#3501641>, @yaxunl wrote:
> If we are to add `__forceinline__` as a keyword, I feel it better be a
> separate patch to be cleaner.
I'm fine with that.
A few nits and a question about the test recently added.
================
Comment at: clang/docs/ReleaseNotes.rst:344-345
-CUDA Language Changes in Clang
+CUDA/HIP Language Changes in Clang
------------------------------
----------------
================
Comment at: clang/include/clang/Basic/AttrDocs.td:543
+avoid diagnostics due to usage of ``__attribute__((__noinline__))``
+with ``__noinline__`` defined as a macro as ``__attribute__((noinline))`.
+
----------------
================
Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }
----------------
yaxunl wrote:
> aaron.ballman wrote:
> > yaxunl wrote:
> > > 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
> > Ah, I just noticed we also have no tests for the behavior of the keyword in
> > the presence of the macro being defined. e.g.,
> > ```
> > #define __noinline__ __attribute__((__noinline__))
> > __noinline__ void fun5() {}
> > ```
> will do
I missed an important detail -- I think this is now going to generate a warning
in `-pedantic` mode (through `-Wkeyword-macro`) when compiling for CUDA; is
that going to be a problem for CUDA headers, or are those always included as a
system header (and so the diagnostics will be suppressed)?
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
