On Thu, 2018-01-11 at 17:32 +, Nick Clifton wrote:
>
> > gcc/ChangeLog:
> > PR target/81819
> > * config/rx/rx.c (rx_is_restricted_memory_address):
> > Handle SUBREG case.
> Go ahead make my day^H^H^H^H^H^H
>
> Approved - please apply.
Committed as r256578 (trunk) and r256579 (GC
On Sat, 2018-01-13 at 03:11 +, Kumar, Venkataramanan wrote:
>
> > My original patch uses "lfence". I was asked to use "pause":
> >
> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>
> If everyone is ok, my suggestion is to use "lfence" as the default
> loop filler for retpoline
On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
>
> WRT text relocs, yea that sucks, but if we're going to have user space
> mitigations, then we're likely going to need those relocs so that the
> thunks can be patched out. I'm actually hoping we're not going to need
> user space mitigations f
On 12/01/18 22:45 -0800, Tim Shen via libstdc++ wrote:
This fixes PR 83601.
OK for trunk, thanks.
On Fri, Jan 12, 2018 at 01:13:17PM -0500, Jason Merrill wrote:
> On Thu, Jan 11, 2018 at 5:11 PM, Paolo Carlini
> wrote:
> > On 11/01/2018 21:33, Jason Merrill wrote:
> >> On 01/10/2018 06:50 PM, Paolo Carlini wrote:
> >>>
> >>> thus the below is a rather "dull" solution at the level of
> >>> cpl
On Sat, Jan 13, 2018 at 12:10:22PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 12, 2018 at 01:13:17PM -0500, Jason Merrill wrote:
> > On Thu, Jan 11, 2018 at 5:11 PM, Paolo Carlini
> > wrote:
> > > On 11/01/2018 21:33, Jason Merrill wrote:
> > >> On 01/10/2018 06:50 PM, Paolo Carlini wrote:
> > >>>
On Sat, Jan 13, 2018 at 12:12:02PM +0100, Jakub Jelinek wrote:
> Or we could not add those error_mark_nodes and
> gcc_assert (seen_error () || cp_parser_error_occurred (parser));
This fixes the testcase:
--- gcc/cp/parser.c.jj 2018-01-11 18:58:48.386391801 +0100
+++ gcc/cp/parser.c 2018-01-
* David Woodhouse:
>> Do you assume that you will eventually apply run-time patching to
>> thunks (in case they aren't needed)?
>
> "eventually"? We've been doing it for weeks. We are desperate to
> release the kernel when can we have agreement on at *least* the
> command line option and the n
On Sat, 2018-01-13 at 13:01 +0100, Florian Weimer wrote:
> * David Woodhouse:
>
> >
> > >
> > > Do you assume that you will eventually apply run-time patching to
> > > thunks (in case they aren't needed)?
> > "eventually"? We've been doing it for weeks. We are desperate to
> > release the kernel
Hi Jakub, all,
> On 13 Jan 2018, at 12:32, Jakub Jelinek wrote:
>
>> On Sat, Jan 13, 2018 at 12:12:02PM +0100, Jakub Jelinek wrote:
>> Or we could not add those error_mark_nodes and
>> gcc_assert (seen_error () || cp_parser_error_occurred (parser));
>
> This fixes the testcase:
> --- gcc/cp/pa
Hello world,
I have committed the patch below as obvious. This one had
the distinction that two people came up with exactly the
same pach independently :-)
Regards
Thomas
2018-01-13 Thomas Koenig
PR fortran/83803
* dump-parse-tree.c (write_
Index: dump-parse
On Sun, 2018-01-07 at 20:55 +, Mike Crowe wrote:
> This patch series was originally submitted back in September at
> https://gcc.gnu.org/ml/libstdc++/2017-09/msg00083.html which ended up
> as https://patchwork.ozlabs.org/cover/817379/ . The patches received
> no comments at all, which may mean
On 01/09/2018 08:23 AM, Richard Sandiford wrote:
> Richard Biener writes:
>> On Mon, Nov 20, 2017 at 12:31 PM, Bin.Cheng wrote:
>>> On Fri, Nov 17, 2017 at 3:03 PM, Richard Sandiford
>>> wrote:
ivopts previously treated pointer arguments to internal functions
like IFN_MASK_LOAD and IFN
On 01/12/2018 03:00 AM, Richard Sandiford wrote:
> Ping.
>
> FWIW, the SLP test failures it fixes were ICEs rather than code-quality
> tests, so this is a correctness fix rather than an optimisation.
>
> Thanks,
> Richard
>
> Richard Sandiford writes:
>> The SVE support for the new CONST_VECTOR
On 01/12/2018 09:28 AM, Richard Sandiford wrote:
>
> Here's the patch with the updated docs. Does this version look OK?
>
> Thanks,
> Richard
>
>
> 2018-01-12 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> gcc/
> * doc/md.texi (vec_mask_load_lanes@var{m
On Fri, Jan 12, 2018 at 9:47 AM, Jan Hubicka wrote:
>> gcc/
>>
>> * config/i386/i386-opts.h (indirect_branch): New.
>> * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
>> * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
>> with local indirect j
> >> +/* Output a funtion with a call and return thunk for indirect branch.
> >> + If BND_P is true, the BND prefix is needed. If REGNO != -1, the
> >> + function address is in REGNO. Otherwise, the function address is
> >> + on the top of stack. */
> >> +
> >> +static void
> >> +output_
Hi Jakub,
>> On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote:
>>> I've been using the following in my tree. Still need to try and get
>>> this upstream.
>>
>> Please. If that doesn't work, I think we need to do it in configure,
>> sanitizer_internal_defs.h seems to be included very e
On Sat, Jan 13, 2018 at 7:56 AM, Jan Hubicka wrote:
>> >> +/* Output a funtion with a call and return thunk for indirect branch.
>> >> + If BND_P is true, the BND prefix is needed. If REGNO != -1, the
>> >> + function address is in REGNO. Otherwise, the function address is
>> >> + on the
On Fri, Jan 12, 2018 at 9:55 AM, Jan Hubicka wrote:
>> Add -mfunction-return= option to convert function return to call and
>> return thunks. The default is 'keep', which keeps function return
>> unmodified. 'thunk' converts function return to call and return thunk.
>> 'thunk-inline' converts fu
On 01/12/2018 09:16 AM, H.J. Lu wrote:
> On Thu, Jan 11, 2018 at 3:00 PM, H.J. Lu wrote:
>> On Thu, Jan 11, 2018 at 2:46 PM, Jeff Law wrote:
>
>>> Do you want to mention that CET and retpolines are inherently
>>
>> I will document it.
>>
>>> incompatible? Should an attempt to use them together
On 01/13/2018 02:03 AM, David Woodhouse wrote:
> On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
>>
>> WRT text relocs, yea that sucks, but if we're going to have user space
>> mitigations, then we're likely going to need those relocs so that the
>> thunks can be patched out. I'm actually hopin
On 01/12/2018 09:03 AM, Jakub Jelinek wrote:
> Hi!
>
> In 7.x and earlier, decl_constant_value_for_optimization punted if
> the initializer has ARRAY_TYPE or BLKmode type, and the following patch
> shows that is reasonable thing to do, otherwise we might grab very large
> initializers out of const
* H. J. Lu:
> On Fri, Jan 12, 2018 at 10:00 AM, Jan Hubicka wrote:
>>> Add 'V', a special modifier which prints the name of the full integer
>>> register without '%'. For
>>>
>>> extern void (*func_p) (void);
>>>
>>> void
>>> foo (void)
>>> {
>>> asm ("call __x86_indirect_thunk_%V0" : : "a" (f
On Sat, 2018-01-13 at 09:17 -0700, Jeff Law wrote:
> On 01/13/2018 02:03 AM, David Woodhouse wrote:
> > On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
> > As things stand with retpoline in the kernel, userspace processes
> > aren't protected from each other. The attack mode is complex and
> >
On Sat, 2018-01-13 at 03:11 +, Kumar, Venkataramanan wrote:
>
> > My original patch uses "lfence". I was asked to use "pause":
> >
> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>
> If everyone is ok, my suggestion is to use "lfence" as the default
> loop filler for retpoline
On Sat, Jan 13, 2018 at 8:28 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> On Fri, Jan 12, 2018 at 10:00 AM, Jan Hubicka wrote:
Add 'V', a special modifier which prints the name of the full integer
register without '%'. For
extern void (*func_p) (void);
void
foo
On Sat, Jan 13, 2018 at 8:34 AM, David Woodhouse wrote:
> On Sat, 2018-01-13 at 03:11 +, Kumar, Venkataramanan wrote:
>>
>> > My original patch uses "lfence". I was asked to use "pause":
>> >
>> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>>
>> If everyone is ok, my suggestion
> > If everyone is ok, my suggestion is to use "lfence" as the default
> > loop filler for retpoline.
can we do BOTH a pause and lfence.
(that way on cpu's where pause is the power stop, it works, and on cpus where
it's a fallthrough (AMD) it goes to the lfence)
On Fri, Jan 12, 2018 at 9:59 AM, Jan Hubicka wrote:
>> Add -mindirect-branch-register to force indirect branch via register.
>> This is implemented by disabling patterns of indirect branch via memory,
>> similar to TARGET_X32.
>>
>> -mindirect-branch= and -mfunction-return= tests are updated with
On Sat, 2018-01-13 at 08:46 -0800, H.J. Lu wrote:
>
> >> +@item -mindirect-branch-register
> >> +@opindex -mindirect-branch-register
> >> +Force indirect call and jump via register.
> >
> > Again I think this option needs better documentation. It is not quite
> > clear to me why
> > it is needed
On Sat, 2018-01-13 at 08:09 -0800, H.J. Lu wrote:
>
> > Again please extend both documentation hunks so it is clear what is purpose
> > of this hack.
>
> David, can you help here?
On most older CPUs the indirect branch issue is limited to actual
indirect branches.
On Skylake-era CPUs, however,
On Sat, Jan 13, 2018 at 05:02:49PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> >> On Mon, Dec 18, 2017 at 11:21:35AM +0100, Rainer Orth wrote:
> >>> I've been using the following in my tree. Still need to try and get
> >>> this upstream.
> >>
> >> Please. If that doesn't work, I think we need to d
On Sat, 2018-01-13 at 08:36 -0800, H.J. Lu wrote:
> On Sat, Jan 13, 2018 at 8:28 AM, Florian Weimer wrote:
> >
> > * H. J. Lu:
> >
> > >
> > > On Fri, Jan 12, 2018 at 10:00 AM, Jan Hubicka wrote:
> > > >
> > > > >
> > > > > Add 'V', a special modifier which prints the name of the full intege
On Sat, Jan 13, 2018 at 8:51 AM, Woodhouse, David wrote:
> On Sat, 2018-01-13 at 08:09 -0800, H.J. Lu wrote:
>>
>> > Again please extend both documentation hunks so it is clear what is purpose
>> > of this hack.
>>
>> David, can you help here?
>
> On most older CPUs the indirect branch issue is li
> On Sat, Jan 13, 2018 at 7:56 AM, Jan Hubicka wrote:
> >> >> +/* Output a funtion with a call and return thunk for indirect branch.
> >> >> + If BND_P is true, the BND prefix is needed. If REGNO != -1, the
> >> >> + function address is in REGNO. Otherwise, the function address is
> >> >>
> On Sat, Jan 13, 2018 at 8:51 AM, Woodhouse, David wrote:
> > On Sat, 2018-01-13 at 08:09 -0800, H.J. Lu wrote:
> >>
> >> > Again please extend both documentation hunks so it is clear what is
> >> > purpose
> >> > of this hack.
> >>
> >> David, can you help here?
> >
> > On most older CPUs the i
I have finally bootstrapped gfortran with the two patches applied and the
spurious warnings with -Wall are now gone (limited testing), but I see a
regression for gfortran.dg/string_1.f90 due to an additional error
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/string_1.f90:13:15:
print *, len(s)
On 01/12/2018 01:51 PM, Jakub Jelinek wrote:
Hi!
Apparently Linux kernel contains various UB code that has been worked around
through -fno-strict-overflow in 7.x and before, but when
POINTER_TYPE_OVERFLOW_UNDEFINED has been removed it now fails to boot.
The following patch follows the comments
On Sat, Jan 13, 2018 at 9:31 AM, Jan Hubicka wrote:
>> On Sat, Jan 13, 2018 at 8:51 AM, Woodhouse, David wrote:
>> > On Sat, 2018-01-13 at 08:09 -0800, H.J. Lu wrote:
>> >>
>> >> > Again please extend both documentation hunks so it is clear what is
>> >> > purpose
>> >> > of this hack.
>> >>
>>
hi,
this patch fixes bug in backward propagation where some BBs can be marked
unlikely for incorrect reason.
Bootstrapped/regtested x86_64-linux,comitted.
Honza
* predict.c (determine_unlikely_bbs): Handle correctly BBs
which appears in the queue multiple times.
Index: predict.c
On 01/12/2018 01:58 PM, li...@coryfields.com wrote:
> From: Cory Fields
>
> 2018-01-12 Cory Fields
>* tree-ira.c (allocno_hard_regs_compare): stabilize sort
> ---
> gcc/ChangeLog | 3 +++
> gcc/ira-color.c | 3 +--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a
I plan to commit the attached patch which eliminates the offending behavior and
allows the test cases to run.
I opened a new PR to address the remaining issues.
See Bug 83829 - Implement runtime checks for DT format specifier and alignment
with effective item.
Regression tested on x86_64-pc-linu
On Sat, Jan 13, 2018 at 2:48 PM, Jeff Law wrote:
> On 01/12/2018 01:58 PM, li...@coryfields.com wrote:
>> From: Cory Fields
>>
>> 2018-01-12 Cory Fields
>>* tree-ira.c (allocno_hard_regs_compare): stabilize sort
>> ---
>> gcc/ChangeLog | 3 +++
>> gcc/ira-color.c | 3 +--
>> 2 files
On 8 January 2018 at 15:36, Jonathan Wakely wrote:
> On 25/12/17 23:59 +0200, Ville Voutilainen wrote:
>>
>> In the midst of the holiday season, the king and ruler of all elves,
>> otherwise
>> known as The Elf, was told by little elves that users are complaining how
>> stlstl and libc++ make opti
Attached is the documentation update for Jakub's recent change
to recognize a cast to void* as a suppression mechanism for
-Wclass-memaccess (the last sentence).
I also reworded the cumbersome first sentence a bit so the diff
looks bigger than the substantive change itself actually is.
Martin
gc
On Sat, Jan 13, 2018 at 8:51 AM, David Woodhouse wrote:
> On Sat, 2018-01-13 at 08:46 -0800, H.J. Lu wrote:
>>
>> >> +@item -mindirect-branch-register
>> >> +@opindex -mindirect-branch-register
>> >> +Force indirect call and jump via register.
>> >
>> > Again I think this option needs better docum
Add 'V', a special modifier which prints the name of the full integer
register without '%'. For
extern void (*func_p) (void);
void
foo (void)
{
asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
}
it generates:
foo:
movqfunc_p(%rip), %rax
call__x86_indirect_thunk
Add -mfunction-return= option to convert function return to call and
return thunks. The default is 'keep', which keeps function return
unmodified. 'thunk' converts function return to call and return thunk.
'thunk-inline' converts function return to inlined call and return thunk.
'thunk-extern' co
Add -mindirect-branch= option to convert indirect call and jump to call
and return thunks. The default is 'keep', which keeps indirect call and
jump unmodified. 'thunk' converts indirect call and jump to call and
return thunk. 'thunk-inline' converts indirect call and jump to inlined
call and re
This set of patches for GCC 8 mitigates variant #2 of the speculative
execution vulnerabilities on x86 processors identified by CVE-2017-5715,
aka Spectre. They convert indirect branches and function returns to
call and return thunks to avoid speculative execution via indirect
call, jmp and ret.
Add -mindirect-branch-register to force indirect branch via register.
This is implemented by disabling patterns of indirect branch via memory,
similar to TARGET_X32.
-mindirect-branch= and -mfunction-return= tests are updated with
-mno-indirect-branch-register to avoid false test failures when
-mi
Since the thunk function may not be reachable in large code model,
-mcmodel=large is incompatible with -mindirect-branch=thunk,
-mindirect-branch=thunk-extern, -mfunction-return=thunk and
-mfunction-return=thunk-extern. Issue an error when they are used with
-mcmodel=large.
gcc/
* config
On Sat, Jan 13, 2018 at 9:30 AM, Jan Hubicka wrote:
>> On Sat, Jan 13, 2018 at 7:56 AM, Jan Hubicka wrote:
>> >> >> +/* Output a funtion with a call and return thunk for indirect branch.
>> >> >> + If BND_P is true, the BND prefix is needed. If REGNO != -1, the
>> >> >> + function address
OK, thanks.
On Sat, Jan 13, 2018 at 6:14 PM, Martin Sebor wrote:
> Attached is the documentation update for Jakub's recent change
> to recognize a cast to void* as a suppression mechanism for
> -Wclass-memaccess (the last sentence).
>
> I also reworded the cumbersome first sentence a bit so the d
Hi,
[This patch supercedes and extends
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01135.html.
There was a small error in the assembly code produced by that patch (bad
memory on my account of how to spell "crset eq"). I've also increased the
function provided; see below.]
This patch adds a ne
Hi,
This is now superceded by
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01204.html.
Sorry for the noise.
Thanks,
Bill
> On Jan 12, 2018, at 4:33 PM, Bill Schmidt wrote:
>
> Hi,
>
> This patch adds a new option for the compiler to produce only "safe" indirect
> jumps, in the sense that t
This libgo patch implements types.SizesFor for gccgo. This
potentially corrects some type sizes, and fixes the vet tool for
alpha, ia64, m68k, and possibly others. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
Hi HJ,
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Sunday, January 14, 2018 9:07 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>
> This set of patches for GCC 8
59 matches
Mail list logo
