================
@@ -8349,6 +8349,19 @@ static bool handleFunctionTypeAttr(TypeProcessingState
&state, ParsedAttr &attr,
return true;
const FunctionType *fn = unwrapped.get();
+
+ // On amdgcnspirv, __cdecl on an abstract function type has no device-side
+ // equivalent, so normalize it to the device default CC to match an
+ // unadorned function type. Skip named decls and variadic types.
+ if (CC == CC_C && S.getLangOpts().CUDAIsDevice &&
----------------
Fznamznon wrote:
SYCL is running into similar problems with Windows headers and we've been
thinking that perhaps SPIR-V could just use CC_C as a default calling
convention on AST level and just map it to spir_func on codegen stage.
There is another problem Windows headers provoke when compiled with SPIR-V
target, consider
```
class A {
public:
virtual void __attribute__((thiscall)) boo() {}
};
class B : public A {
virtual void boo() override {}
};
```
It provokes errors when compiled for SPIR targets.
The problem here is that `boo` has default calling convention which is
CC_SpirFunction and `foo` has thiscall calling convetion which is transformed
to `CC_C` in most cases. This can be solved if SPIR-V targets use `CC_C`
calling convention on AST level.
cc @tahonermann @schittir
https://github.com/llvm/llvm-project/pull/210882
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
