On Fri, Aug 26, 2011 at 9:30 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.
I will wait for the confirmation from Rainer before committing the patch.
Uros.
