On Thu, 25 Aug 2011, Uros Bizjak wrote:

> Hello!
> 
> 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.

Thanks,
Richard.

Reply via email to