================
@@ -5743,10 +5743,11 @@ bool Sema::CheckCallingConvAttr(const ParsedAttr
&Attrs, CallingConv &CC,
bool IsTargetDefaultMSABI =
Context.getTargetInfo().getTriple().isOSWindows() ||
Context.getTargetInfo().getTriple().isUEFI();
+ const TargetInfo &TI = Context.getTargetInfo();
// TODO: diagnose uses of these conventions on the wrong target.
switch (Attrs.getKind()) {
case ParsedAttr::AT_CDecl:
- CC = CC_C;
+ CC = LangOpts.SYCLIsDevice ? TI.getDefaultCallingConv() : CC_C;
----------------
tahonermann wrote:
I agree we should do something different here.
Note that this change wouldn't necessarily avoid all possible use of `CC_C`
anyway; see line 5923 below as one example. If `checkCallingConvention()`
returns `TargetInfo::CCCR_Ignore`, the calling convention will get defaulted to
`CC_C` there.
The diagnostic this PR is intended to address is exemplified by [this Compiler
Explorer example](https://godbolt.org/z/oGPE8vf44), correct? Are there examples
that generate other diagnostics?
It isn't clear to me what the desired behavior is. Should any of the functions
that are explicitly declared with `__cdecl` in Microsoft headers be callable by
device code? I assume not in which case we might be better off relaxing the
"function declared 'cdecl' here was previously declared without calling
convention" diagnostic (`diag::err_cconv_change`) when the conflict involves a
previous implicit declaration. The diagnostic is issued in
`Sema::MergeFunctionDecl()` which already has some cases where a conflicting
calling convention is discarded on a redeclaration (with a warning), so we can
probably do similarly without much effort.
https://github.com/llvm/llvm-project/pull/200195
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
