On Mon, 1 Aug 2016, Joseph Myers wrote: > 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).
So I read your comment as a general remark and not as an objection to the patch in question? Richard.