On Wed, 2 Nov 2016, James Greenhalgh wrote:
> 2016-11-02 James Greenhalgh
>
> * target.def (excess_precision): New hook.
> * target.h (flt_eval_method): New.
> (excess_precision_type): Likewise.
> * targhooks.c (default_excess_precision): New.
> * targhooks.h (def
gcc/testsuite/ChangeLog:
2016-11-09 Kito Cheng
PR target/78230
* gcc.dg/torture/pr66178.c (test): Use uintptr_t instead of int.
(test2) Ditto.
From 73ff22745720ecfc2a33148f68ff7e0f36c1144b Mon Sep 17 00:00:00 2001
From: Kito Cheng
Date: Wed, 9 Nov 2016 10:39:59 +0800
Su
This change also verified with gcc 6.1 and 5.4
it can pass with gcc 6.1 and make gcc 5.4 ICE after this change.
On Wed, Nov 9, 2016 at 10:43 AM, Kito Cheng wrote:
> gcc/testsuite/ChangeLog:
>
> 2016-11-09 Kito Cheng
>
> PR target/78230
> * gcc.dg/torture/pr66178.c (test): Use ui
On Wed, 2 Nov 2016, James Greenhalgh wrote:
> OK, I've reworked the patch along those lines. I noticed that the original
> logic looked for
>
> && TARGET_FLT_EVAL_METHOD != 0
>
> And I no longer make that check. Is that something I need to reinstate?
No, the replacement logic should imply
The -fprintf-return-value optimization has been disabled since
the last time it caused a bootstrap failure on powerpc64le. With
the underlying problems fixed GCC has bootstrapped fine on all of
powerpc64, powerpc64le and x86_64 and tested with no regressions.
I'd like to re-enable the option. Th
On Tue, Nov 8, 2016 at 2:11 AM, kugan wrote:
> Hi,
>
> On 04/11/16 03:24, Martin Jambor wrote:
>>
>> Hi,
>>
>> On Fri, Oct 28, 2016 at 01:58:13PM +1100, kugan wrote:
Do I understand it correctly that extract_range_from_unary_expr deals
with any potential type conversions better (com
101 - 106 of 106 matches
Mail list logo