<div dir="ltr">IIRC the two types are guaranteed to be layout compatible between C and C++ so there should be no abstraction penalty here?<div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 24, 2020 at 9:03 AM Jean Perier via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">jeanPerier added a comment.<br>
<br>
In this very spot, the goal of the template is to digest the runtime headers in order to lower their function signature to an `mlir::FuncOp` declaration that is compatible with the runtime and will be call in user programs.<br>
So if we use `std::complex` here and introduce a wrapper indirection in C around the runtime, then the cost of this indirection will be paid by the user program. I am not comfortable with having a Fortran programmer pay the price of a C/C++ compatibility issues.<br>
<br>
However, you are absolutely correct that in this very code spot we are discussing, using `_Complex` is not essential. All we need to know "this runtime interface is using C99 complex", so we could define a type like  `Fortran::common::C99complex<T>` instead, and  use it as a tag here.<br>
<br>
In folding the the C99 `_Complex` functions are called from C++ the code around the comment I linked above is dealing with this interface (or was, since part of it was reverted). Your wrappers would be a solution here given folding performance is not as critical, but given folding with pgmath is the non-default option (under ifdef, I think it is easier to only enable it if `_Complex` of `_FComplex` is available and resort to the default usage of cmath in the other cases.<br>
<br>
Thanks for pointing out we do not really use the interface in this very spot ! I think I can now put up a solution that should fulfill all wishes:<br>
<br>
- no warnings, compiles on all C++ compliant compiler.<br>
- no silent undefined behavior for X86_32 and the whatever other ABI out there deals with _Complex in a special way<br>
- no user program performance hit<br>
- still possible to fold with pgmath if you are using a mainstream C++ compiler to compile flang (g++, clang++, msvc when possible)<br>
- no hard error if using pgmath complex functions is not possible<br>
- not too much additional code complexity in flang or the runtime.<br>
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D83397/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D83397/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D83397" rel="noreferrer" target="_blank">https://reviews.llvm.org/D83397</a><br>
<br>
<br>
<br>
</blockquote></div>