Re: [Patch 1/11] Add a new target hook for describing excess precision intentions

2016-11-08 Thread Joseph Myers
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

[PATCH] Fix PR78230

2016-11-08 Thread Kito Cheng
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

Re: [PATCH] Fix PR78230

2016-11-08 Thread Kito Cheng
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

Re: [Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION

2016-11-08 Thread Joseph Myers
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

[PATCH] enable -fprintf-return-value by default

2016-11-08 Thread Martin Sebor
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

Re: [ipa-vrp] ice in set_value_range

2016-11-08 Thread Andrew Pinski
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

<    1   2