This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 09 Apr 2016 13:35:34 +0200
- Subject: Re: [PATCH] Fix ifcombine (PR tree-optimization/70586)
- Authentication-results: sourceware.org; auth=none
- References: <20160408171648 dot GZ19207 at tucnak dot redhat dot com> <5BCE45D4-6C6E-4B88-BFDD-E4FDA73A1134 at suse dot de> <20160408200058 dot GD19207 at tucnak dot redhat dot com> <41ABD7AF-7858-4A08-92FD-416B49A4CCFC at suse dot de> <E9649124-118B-4DDB-821A-C8E407C8F18C at suse dot de> <20160409112951 dot GE19207 at tucnak dot redhat dot com>
On April 9, 2016 1:29:51 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>On Sat, Apr 09, 2016 at 01:21:06PM +0200, Richard Biener wrote:
>> To followup myself here - we can also make sure the function doesn't
>become pure/const.
>>
>> Similar issues exist with pure/const functions with ops with
>undefined overflow (and code gen taking advantage of that).
>> So it's not only trapping that needs to be guarded against... :/
>
>But then we'd probably want 2 categories, keep pure/const meaning it
>had
>(that allows trapping/FPU exceptions, because, aren't most of libm
>const
>functions in this category?), and then have another attributes for
>functions
>that can't trap/don't use FPU etc.
I have to think about this. We need to look at the user documented semantics of pure/const and need to decide where
We can directly use them in the middle end and where we need some 'derived'
Property instead.
>Anyway, I've committed the patch and will change the PR to be
>7/Regression,
>so that it is not forgotten.
Thanks,
Richard.
> Jakub