<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 3, 2015 at 2:46 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 Sat, Oct 03, 2015 at 08:43:49AM -0700, Tim Northover wrote:<br>
> Hi Joerg,<br>
><br>
> On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > while debugging assertions when building libm for 32bit Sparc, I hit the<br>
> > following IR:<br>
> ><br>
> >   complex_mul_libcall:<br>
> >     call void @__muldc3({ double, double }* sret %tmp, double %conv, double 0.000000e+00, double %a.real, double %a.imag) #2<br>
> ><br>
> >   ...<br>
> ><br>
> >   declare void @__muldc3({ double, double }*, double, double, double, double)<br>
> ><br>
> > The same IR is essentially generated for i386 too, so it is not Sparc<br>
> > specific. Unlike i386, Sparc has an assertion in its codegen that the<br>
> > function called must have the sret attribute on corresponding argument.<br>
><br>
> I think we should view this as a special case of bitcasting functions<br>
> to different types (not quite types because it turns out function<br>
> attributes aren't part of the type in IR, but morally the same thing).<br>
> LLVM allows those casts normally.<br>
<br>
</span>Well, we do consider it an ABI changing attribute for the purpose of<br>
tail call (under "musttail") and we are loosing the dereferencable<br>
information. Removing the assert is easy, I just want to make sure there<br>
is consensus it is the right thing to do.<br></blockquote><div><br></div><div>I think the assertion is probably overzealous and would fire when it shouldn't in an LTO setting, but it sounds like it also caught a real clang bug.</div><div><br></div><div>This seems like one of those things that's supposed to be in the "lint" pass, but isn't, because lint isn't part of the normal clang pass pipeline.</div></div></div></div>