On Mon, 1 Aug 2016, Richard Biener wrote: > On Mon, 1 Aug 2016, Joseph Myers wrote: > > > On Mon, 1 Aug 2016, Richard Biener wrote: > > > > > I don't think so - the pattern is as much a canonicalization as an > > > optimization. If the target cannot expand copysign then the > > > middle-end expander should try an alternative like the a / abs(x) > > > form. Though if copysign cannot be open-coded then I don't see > > > how abs can be opencoded (which basically is copysign (1.0, x)). > > > > It's expanded incorrectly in those cases (see bug 29253). > > Heh, looks like I worked on this 8 years ago... > > Fixing the copysign expansion issue should be as easy as > making sure expand_copysign_absneg is not used if the mode > has signed zeros.
Correct expansion of abs or copysign for IBM long double (i.e., for the case where signbit_rw for the format is -1) requires special logic for that format; inhibiting particular incorrect expansion code may cause an external function call to be used in place of an incorrect inline expansion, but that won't help if you care about avoiding such a function call to fabsl or copysignl. The logic for IBM long double isn't that complicated - a few bitwise manipulations - but we don't have it at present (for that soft-float case). -- Joseph S. Myers jos...@codesourcery.com
