<div dir="ltr"><div class="gmail_extra">A temporary workaround is defining __mulsc3 in your own code... clang seems to pick up on it correctly, e.g.:</div><div class="gmail_extra"><pre>__attribute__(( always_inline ))
static inline  float _Complex
__mulsc3( float ar, float ai, float br, float bi)
{
        return (float _Complex){  ar * br - ai * bi,  ar * bi + ai * br  };
}</pre></div><div class="gmail_extra"><br></div><div class="gmail_extra">I've noticed it really needs to be static always_inline to get optimized properly. At least using latest clang-3.7 from debian sid with:</div><div class="gmail_extra"><font face="monospace, monospace">-target arm-linux-gnueabihf -mfloat-abi=hard -mcpu=cortex-a8 -mfpu=neon -Ofast</font></div><div class="gmail_extra"><br></div><div class="gmail_extra">Different storage class specifications give fascinating differences, even with a function as simple as<font face="monospace, monospace"> return a * b; </font>where a and b are its complex float arguments.</div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">Two curious observations:</div><div class="gmail_extra">* If my __mulsc3 is declared "extern inline", clang nevertheless emits code for it. I had expected any non-inlineable uses to become references to the standard one.</div><div class="gmail_extra">* If it is declared static (inline or not) it acquires soft float ABI calling conventions (with associated terrible overhead), and it still gets called in places where __mulsc3 would normally get called. Using always_inline avoids this.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(Since you're declaring complex mul, you can of course take the opportunity to see if there's any benefit in a different implementation of complex multiply, e.g.</div><div class="gmail_extra"><pre>     float t = ai * ( br - bi );
        return (float _Complex){  br * (ar - ai) + t,  bi * (ar + ai) + t  };
</pre></div><div class="gmail_extra">or one of its many variants. Probably not unless your target has a slow multiplier or the relevant sums/differences are needed already anyway, but who knows...)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Matthijs</div></div></div>