On Fri, 26 Aug 2011, Uros Bizjak wrote:
> On Fri, Aug 26, 2011 at 9:05 AM, Richard Guenther <rguent...@suse.de> wrote:
>
> >> As noted in the PR, we also have to protect conversion from
> >> round->lround for non-TARGET_C99_FUNCTIONS targets. Otherwise, gcc
> >> chokes in fold_fixed_mathfn, trying to canonicalize iround to
> >> (non-existent) lround. It looks to me, that we can trigger the same
> >> problem trying to convert (long long) round -> llround -> lround on
> >> non-TARGET_C99_FUNCTIONS LP64 targets, so this fix probably applies to
> >> other release branches as well.
> >>
> >> 2011-08-25 Uros Bizjak <ubiz...@gmail.com>
> >>
> >> PR middle-end/50083
> >> * convert.c (convert_to_integer) <BUIT_IN_ROUND{,F,L}>: Convert
> >> only when TARGET_C99_FUNCTIONS.
> >> <BUILT_IN_NEARBYINT{,F,L}>: Ditto.
> >> <BUILT_IN_RINT{,F,L}>: Ditto.
> >>
> >> Bootstrapped on x86_64-pc-linux-gnu, regtesting in progress.
> >>
> >> OK for SVN and 4.6?
> >
> > Hmm. In builtins.c we usually check if the target has support to
> > expand the builtins directly in case we have named patterns for them.
> > IMHO these convert.c optimizations belong somewhere else (so that
> > they trigger for all languages). Somewhere else these days would
> > be tree-ssa-forwprop.c.
> >
> > I'm not asking you to do this move but please consider also doing
> > the optimization when the target can expand the function directly.
>
> Yes, I know from our previous communication (ilogb handling) that this
> whole convert.c part is fishy, but my attached patch fixes the
> unwanted conversion in the same way as other similar builtins are
> handled.
Hmm, right, I see that now.
Well, patch is ok then.
Thanks,
Richard.
