[PATCH][RFA/RFC] Stack clash mitigation patch 05/08

I don't think this has changed in any significant way since V1. -- The prior patch introduced -fstack-clash-protection prologues for the x86. And yet we still saw large allocations in our testing. It turns out combine-stack-adjustments would take allocate PROBE_INTERVAL probe allocate PROBE_I

[PATCH][RFA/RFC] Stack clash mitigation patch 06/08 V2

These are the PPC bits for stack clash mitigation. As noted before the PPC bits were larger/more complex than other ports. Part of that was due to the PPC defining its own dynamic stack allocation expander -- which in turn means we weren't using any of the generic code in explow.c for stack c

[PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

So this patch has changed considerably since V1 as well. First, we no longer track the bulk of the register stores in the prologue. Those may be separately shrink wrapped and thus not executed on all paths and as such are not candidates for implicit probes. Second, per the discussions we've had

[PATCH][RFA/RFC] Stack clash mitigation patch 04/08 V2

I don't think this has changed in any significant way since V1. -- This patch introduces x86 target specific bits to mitigate stack clash attacks. The key differences relative to the -fstack-check=specific expander are that it never allocates more than PROBE_INTERVAL bytes at a time, it probes i

[PATCH][RFA/RFC] Stack clash mitigation patch 08/08 V2

I don't think this patch has changed in any significant way since the V1 patch. I have tested a slightly different version which punts stack clash protection for very large static stack frames -- otherwise tests which have *huge* frames will timeout, run out of memory during compilation, etc. --

[PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2

This time with the patch attached. Forwarded Message Subject: [PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2 Date: Tue, 18 Jul 2017 23:17:23 -0600 From: Jeff Law To: gcc-patches The biggest change since V1 of this patch is dropping the changes to STACK_CHECK_MOVIN

[PATCH][RFA/RFC] Stack clash mitigation patch 03/08 V2 -- right patch attached

Opps, I clearly attached the wrong file. -- I don't think this patch changed in any significant way since V1. -- One of the painful aspects of all this code is the amount of target dependent bits that have to be written and tested. I didn't want to be scanning assembly code or RTL for prologue

Re: [patch] Fix Unwind support on DragonFly BSD after sigtramp move

On 07/07/2017 05:17 PM, John Marino wrote: > Right after DragonFly 4.8 was released (27 Mar 2017), the signal > trampoline was moved (twice) in response to a Ryzen bug. This broke > GCC's unwind support for DragonFly. > > To avoid hardcoding the sigtramp location to avoid issues like this in > th

Re: [PATCH v2] Add no_tail_call attribute

On 07/03/2017 12:08 PM, Yuri Gribov wrote: >>> 0001-Added-no_tail_call-attribute.patch >>> >>> >>> From 1f4590e7a633c6335512b012578bddba7602b3c9 Mon Sep 17 00:00:00 2001 >>> From: Yury Gribov >>> Date: Sun, 28 May 2017 21:02:20 +0100 >>> Subject: [PATCH] Added no_tail_call attribute. >>> >>> gcc/

Re: [PATCH] Transform (m1 > m2) * d into m1> m2 ? d : 0

On 07/04/2017 05:13 AM, Hurugalawadi, Naveen wrote: > Hi, > > Thanks for the review and comments on the patch. > >>> The proposed patch handled both the same. This means the pattern >>> shouldn't use range-info but instead match a more complex > > The patch handles as per the discussion by matc

Re: [PATCH 1/2] simplify-rtx: The truncation of an IOR can have all bits set (PR81423)

On 07/18/2017 01:36 PM, Segher Boessenkool wrote: > ... if it is an IOR with a constant with all bits set in the mode > that is truncated to, for example. Handle that case. > > With this patch the problematic situation for the PR81423 testcase > isn't even reached; but the next patch fixes that a

Re: [PATCH] enhance -Wrestrict for sprintf %s arguments

On 07/02/2017 02:00 PM, Martin Sebor wrote: > The attached patch enhances the -Wrestrict warning to detect more > than just trivial instances of overlapping copying by sprintf and > related functions. > > The meat of the patch is relatively simple but because it introduces > dependencies between e

Re: [PATCH 3/6] lra-assigns.c: fix pseudo_compare_func

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > This comparator lacks anti-commutativity and can indicate > A < B < A if both A and B satisfy non_spilled_static_chain_regno_p. > Proceed to following tie-breakers in that case. > > (it looks like the code incorrectly assumes that at most one regi

Re: [PATCH 2/6] gimple-ssa-store-merging.c: fix sort_by_bitpos

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > This qsort comparator lacks anti-commutativity and can indicate > A < B < A if A and B have the same bitpos. Return 0 in that case. > > * gimple-ssa-store-merging.c (sort_by_bitpos): Return 0 on equal bitpos. OK. jeff

Re: [PATCH 1/6] tree-vrp: fix compare_assert_loc qsort comparator

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > Subtracting values to produce a -/0/+ comparison value only works when > original values have limited range. Otherwise it leads to broken > comparator that indicates 0 < 0x4000 < 0x8000 < 0. > > Yuri posted an equivalent patch just a few

Re: [PATCH] Fix an UBSAN test-case (PR sanitizer/63361).

On 07/18/2017 01:49 PM, Jakub Jelinek wrote: On Tue, Jul 18, 2017 at 01:44:21PM +0200, Martin Liška wrote: gcc/testsuite/ChangeLog: 2017-07-17 Martin Liska PR sanitizer/63361 * c-c++-common/ubsan/float-cast-overflow-1.c: Add either -ffloat-store or -mieee for targets

<    1   2