<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 6, 2015 at 2:02 PM, Joerg Sonnenberger via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Oct 06, 2015 at 01:33:17PM -0700, Reid Kleckner wrote:<br>
> You could imagine that __muldc3 might be implemented in C, and it might be<br>
> implemented without using _Complex so that it can be compiled by a compiler<br>
> without _Complex support. Instead of using a _Complex double return type,<br>
> it would use a pointer outparam as the first parameter, and it would return<br>
> that pointer as usual in RAX. Yes, this is a prototype mismatch and<br>
> probably UB according to C, but this might be part of an implementation<br>
> which knows something about the platform lowering.<br>
<br>
</span>This argument is really not convincing to me. If you have LLVM IR, you<br>
are starting from a frontend that should be supporting complex already.<br>
This really sounds like a case that should be flagged to fix up legacy<br>
code and not something to silently hide. Does code like this (manually<br>
turning structure returns into explicit pointers) actually exist? Note<br>
that the normal way for doing the complex thing is to define a two<br>
element structure, which would still give the sret.</blockquote><div><br></div><div>Basically, LLVM shouldn't assert if Clang produces prototype mismatches, because they happen in practice. Clang tries really hard to avoid prototype mismatches. It even has it's own set of assertions in call lowering to detect them. However, at the end of the day, sometimes it has incomplete function pointer type information and mismatches happen. An ABI attribute mismatch is just another type mismatch, but it doesn't require bitcasts, so it's less obvious.</div><div><br></div><div>I mention LTO because that's where most prototype mismatches come up: one TU saw a complete pointer to parameter type and the other didn't, and now things look quite different. I'm just saying it happens, and LLVM should try to be careful.</div></div></div></div>