On Wed, Aug 02, 2017 at 10:40:32AM -0600, Jeff Law wrote:
> On 07/31/2017 05:25 PM, Segher Boessenkool wrote:
> > This changes combine to always use insn_cost, not pattern_cost. I don't
> > intend to commit it like this: it calls recog more often than necessary,
> > and it is very ugly (no, don't
OK.
On Wed, Aug 2, 2017 at 5:15 PM, Paolo Carlini wrote:
> Hi,
>
> by and large this issue seems already fixed in mainline, ie, we don't ICE
> anymore during error recovery, but I noticed that we try to prettyprint
> constructor and destructor as expressions and we end up with ugliness like:
>
>
* Jeff Law:
> Something like setup a signal handler when we first start unwinding that
> flags the error and tear it down when we're done unwinding?Obviously
> we can't do setup/tear down each time for each address. Anyway, just
> thinking outloud here...
Linux doesn't have per-thread signal
This adds a pipeline description for the Qualcomm Falkor core. This was
tested with a bootstrap and make check. There were no regressions. This
gives about 0.5% performance gain on SPEC CPU2006 on our internal tree, which
has a few other patches that aren't in the FSF tree yet.
OK?
Jim
On Wed, Aug 02, 2017 at 12:17:44PM -0600, Jeff Law wrote:
> So this has probably been hashed to death, but just a couple thoughts.
>
> I think realistically one has to look at the entirety of the PARALLEL to
> get any reasonable costing.
>
> Summing the individual components is wrong. Taking the
On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov wrote:
> On 02.08.2017 21:48, H.J. Lu wrote:
>>
>> On Wed, Aug 2, 2017 at 1:39 PM, Yury Gribov
>> wrote:
>>>
>>> On 02.08.2017 20:02, Jeff Law wrote:
On 08/02/2017 12:47 PM, Jakub Jelinek wrote:
>
>
> On Wed, Aug 02, 2017 at 1
From: Qing Zhao
Date: Wed, 2 Aug 2017 14:41:51 -0500
> so, could you please specify what kind of side effects will have
> when set STRICT_ALIGNMENT to true on TARGET_MISALIGN?
Why don't you read the code rather than just relying upon what
high level description is given by the documentation inst
My first version of this patch inited m->fs.sp_realigned_fp_last with
the value of m->fs.sp_offset prior to performing the stack realignment.
I had forgotten, however, that when we're saving GP regs using MOV that
we delay SP modification as long as possible so that the value of
m->fs.sp_offset at
Hi Bill,
On Wed, Aug 02, 2017 at 10:29:20AM -0500, Bill Schmidt wrote:
> I don't anticipate backporting any of this.
Good :-)
> @@ -6802,7 +6802,7 @@ altivec_resolve_overloaded_builtin (location_t loc
> if (unsupported_builtin)
>{
> const char *name = rs6000_overloaded_builtin
Jeff Law:
> On 07/21/2017 10:15 AM, Ximin Luo wrote:
>> (Please keep me on CC, I am not subscribed)
>>
>>
>> Proposal
>>
>>
>> This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP. When
>> this is set, GCC will treat this as extra implicit
>> "-fdebug-prefix-map=$value"
On 02.08.2017 23:04, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov wrote:
On 02.08.2017 21:48, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 1:39 PM, Yury Gribov
wrote:
On 02.08.2017 20:02, Jeff Law wrote:
On 08/02/2017 12:47 PM, Jakub Jelinek wrote:
On Wed, Aug 02, 2017 at 12:3
On 03.08.2017 3:06, Ximin Luo wrote:
Jeff Law:
On 07/21/2017 10:15 AM, Ximin Luo wrote:
(Please keep me on CC, I am not subscribed)
Proposal
This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP. When
this is set, GCC will treat this as extra implicit "-fdebug-pref
On 02/08/17 21:30, Jeff Law wrote:
On 07/24/2017 12:03 AM, Sebastian Huber wrote:
gcc/
PR libgcc/61152
* aarch64/rtems.h: Add GCC Runtime Library Exception. Format
changes.
* arm/rtems.h: Likewise.
* bfin/rtems.h: Likewise.
* i386/rtemself.h: Li
101 - 113 of 113 matches
Mail list logo
