[PATCH] D31397: [Bug 25404] Fix crash on typedef in OpenCL 2.0

Alexey Bader via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 28 05:20:29 PDT 2017


bader added inline comments.


================
Comment at: lib/Sema/SemaDecl.cpp:2157
   if (getDiagnostics().getSuppressSystemWarnings() &&
-      (Context.getSourceManager().isInSystemHeader(Old->getLocation()) ||
+      // Some standard types are defined implicitly in Clang (e.g. OpenCL).
+      (Old->isImplicit() || New->isImplicit() ||
----------------
Anastasia wrote:
> Anastasia wrote:
> > ahatanak wrote:
> > > Is it necessary to check whether New is implicit? I was just wondering when or how an implicit definition would redefine a typedef.
> > I had a thought on it too, and I am not sure actually. This can happen if we implicitly define something from the standard headers. But I believe the Sema initialization should always happen before parsing the standard header or even loading them from the PCH. So I guess this shouldn't ever happen really? Perhaps, I should just remove this?
> Actually in case of implicit typedefs we don't seem to follow this program path at all. So I am removing this.
So something like this will also work?
```
typedef float float4 __attribute((ext_vector_type(4)));
typedef float4 atomic_int;
```



================
Comment at: test/SemaOpenCL/types.cl:6
+// Check redefinition of standard types
+typedef atomic_int atomic_flag;
----------------
Can we check that -Wtypedef-redefinition will emit a warning for this expression?
This typedef seems to be unnecessary since clang implicitly defines atomic_flag for OpenCL. User is not supposed to re-define it, so warning would be helpful here.


https://reviews.llvm.org/D31397





More information about the cfe-commits mailing list