Re: [PATCH 2/6] New warnings -Wstring-plus-{char, int} (PR c++/62181)

2017-06-19 Thread Xi Ruoyao
On 2017-06-19 12:44 -0600, Martin Sebor wrote: > On 06/19/2017 11:28 AM, Xi Ruoyao wrote: > > On 2017-06-19 10:51 -0600, Martin Sebor wrote: > > > On 06/11/2017 07:32 PM, Xi Ruoyao wrote: > > > > This patch adds warning option -Wstring-plus-int for C/C++. > > > > > > > > gcc/ChangeLog: > > > > >

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jakub Jelinek
On Mon, Jun 19, 2017 at 01:04:57PM -0600, Jeff Law wrote: > On 06/19/2017 11:50 AM, Joseph Myers wrote: > > On Mon, 19 Jun 2017, Jeff Law wrote: > > > >> A key point to remember is that you can never have an allocation > >> (potentially using more than one allocation site) which is larger than a >

Forward list default default and move constructors

2017-06-19 Thread François Dumont
Hi Here is the patch to default the default and move constructors on the std::forward_list. Putting a move constructor on _Fwd_list_node_base helped limiting the code impact of this patch. It doesn't have any side effect as iterator types using this base type are not defining any move sem

C++ PATCH for c++/80562, ICE with C++17 constexpr if

2017-06-19 Thread Jason Merrill
We need to call instantiate_non_dependent_expr before cxx_constant_value in a template. Tested x86_64-pc-linux-gnu, applying to trunk and 7. commit 1645e51aeab6cea4e7206cb6a3520eaf383e47f6 Author: Jason Merrill Date: Mon Jun 19 15:47:47 2017 -0400 PR c++/80562 - ICE with constexpr

C++ PATCH for c++/80829, ICE with constexpr copy of base

2017-06-19 Thread Jason Merrill
The constexpr code uses the CONSTRUCTOR_NO_IMPLICIT_ZERO flag to track partially-initialized aggregates, but we were failing to clear it on base subobjects. Tested x86_64-pc-linux-gnu, applying to trunk and 7. commit 2e3142bcd6fde9f9ac22928718e55584a6255286 Author: Jason Merrill Date: Mon Jun 1

Re: [PATCH/AARCH64] Improve/correct ThunderX 1 cost model for Arith_shift

2017-06-19 Thread Andrew Pinski
On Wed, Jun 7, 2017 at 10:16 AM, James Greenhalgh wrote: > On Fri, Dec 30, 2016 at 10:05:26PM -0800, Andrew Pinski wrote: >> Hi, >> Currently for the following function: >> int f(int a, int b) >> { >> return a + (b <<7); >> } >> >> GCC produces: >> add w0, w0, w1, lsl 7 >> But for ThunderX

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 01:45 PM, Jakub Jelinek wrote: > On Mon, Jun 19, 2017 at 01:04:57PM -0600, Jeff Law wrote: >> On 06/19/2017 11:50 AM, Joseph Myers wrote: >>> On Mon, 19 Jun 2017, Jeff Law wrote: >>> A key point to remember is that you can never have an allocation (potentially using more tha

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 11:51 AM, Jakub Jelinek wrote: > On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote: >> On 06/19/2017 11:29 AM, Jakub Jelinek wrote: >>> >>> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack, >>> while it is shorter, is it actually faster or as slow as movq $

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Joseph Myers
On Mon, 19 Jun 2017, Florian Weimer wrote: > I think architectures such as aarch64 without implied stack probing as > part of the function call sequence would benefit most from an ABI > agreement (splitting the probing responsibility in some way between > caller and callee). For architectures wit

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 12:15 PM, Florian Weimer wrote: > On 06/19/2017 08:02 PM, Richard Biener wrote: >> Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095 >> would solve the signal atomicity as well. Might be larger and somewhat >> interfere with CPUs stack engine. Who knows... >

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 03:56 PM, Joseph Myers wrote: > On Mon, 19 Jun 2017, Florian Weimer wrote: > >> I think architectures such as aarch64 without implied stack probing as >> part of the function call sequence would benefit most from an ABI >> agreement (splitting the probing responsibility in some way b

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 12:12 PM, Richard Kenner wrote: > Out of curiousity, does the old Alpha/VMS stack-checking API meet the > requirements? From what I recall, I think it does. Unsure. Is this documented somewhere? jeff

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Richard Kenner
> > Out of curiousity, does the old Alpha/VMS stack-checking API meet the > > requirements? From what I recall, I think it does. > Unsure. Is this documented somewhere? It seems to be in http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04621389 starting at page 3-54.

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Jeff Law
On 06/19/2017 12:02 PM, Richard Biener wrote: > On June 19, 2017 8:00:19 PM GMT+02:00, Richard Biener > wrote: >> On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek >> wrote: >>> On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote: After much poking around I concluded that we really

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

2017-06-19 Thread Florian Weimer
On 06/20/2017 12:05 AM, Jeff Law wrote: > On 06/19/2017 03:56 PM, Joseph Myers wrote: >> On Mon, 19 Jun 2017, Florian Weimer wrote: >> >>> I think architectures such as aarch64 without implied stack probing as >>> part of the function call sequence would benefit most from an ABI >>> agreement (spli

Re: [PATCH][AArch64] Mark symbols as constant

2017-06-19 Thread Richard Earnshaw
On 19/06/17 19:59, Wilco Dijkstra wrote: > Aarch64_legitimate_constant_p currently returns false for symbols, > eventhough they are always valid constants. This means LOSYM isn't > CSEd correctly. If we return true CSE works better, resulting in > smaller/faster code (0.3% smaller code on SPEC200

Re: [PATCH, rs6000] Fix vec_mulo and vec_mule instruction generation

2017-06-19 Thread Segher Boessenkool
Hi Carl, On Fri, Jun 16, 2017 at 02:19:05PM -0700, Carl Love wrote: > * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add Indent is broken on this line. > ALTIVEC_BUILTIN_VMULESW, ALTIVEC_BUILTIN_VMULEUW, > ALTIVEC_BUILTIN_VMULOSW, ALTIVEC_BUILTIN_VMULOUW enties. T

Re: [PATCH, rev 2] PR target/79799, Add vec_insert of V4SFmode on PowerPC ISA 3.0 (power9)

2017-06-19 Thread Segher Boessenkool
On Fri, Jun 16, 2017 at 05:55:35PM -0400, Michael Meissner wrote: > Here is the latest patch that restricts the optimization to 64-bit (due to > needing VSX small integers). I've done a full bootstrap/make check on a > little > endian power8 system, and a build without bootstrap and make check on

Re: [PATCH rs6000] Fix for commit 249311

2017-06-19 Thread Segher Boessenkool
On Fri, Jun 16, 2017 at 09:08:50PM -0700, Carl Love wrote: > Commit r249311 had an error. During the patch review the define expand > for VFC_inst was changed to VF_sxddp. I compiled and tested the source > after making the change and it seemed fine. However, I missed a couple > of changes. It

Backport of r244010 to gcc-6-branch

2017-06-19 Thread Jack Howarth
The following change from gcc-7-branch and trunk needs to be backported to gcc-6-branch to allow the Xcode 9 clang compiler to bootstrap it. Tested on 10.12 with Xcode 9 beta. Okay for gcc-6-branch? Jack r244010-gcc_6_branch-backport.patch Description: Binary data

Re: [PATCH][AArch64] Allow const0_rtx operand for atomic compare-exchange patterns

2017-06-19 Thread Andrew Pinski
On Tue, Feb 28, 2017 at 4:29 AM, Kyrill Tkachov wrote: > Hi all, > > For the testcase in this patch we currently generate: > foo: > mov w1, 0 > ldaxr w2, [x0] > cmp w2, 3 > bne .L2 > stxrw3, w1, [x0] > cmp w3, 0 > .L2: >

Re: [PATCH] Fix x86 ICE with -mtune=amdfam10 -mno-sse2 (PR target/81121)

2017-06-19 Thread Uros Bizjak
On Mon, Jun 19, 2017 at 5:37 PM, Jakub Jelinek wrote: > Hi! > > This testcase started to ICE when PR70873 fix changed the splitter: > @@ -5153,11 +5147,11 @@ > ;; slots when !TARGET_INTER_UNIT_MOVES_TO_VEC disables the general_regs > ;; alternative in sse2_loadld. > (define_split > - [(set (ma

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

2017-06-19 Thread Sebastian Huber
Hello, would someone mind reviewing this patch please. It was already sent for review on January this year and got no attention. Now we are in a different development stage. https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01354.html -- Sebastian Huber, embedded brains GmbH Address : Dornierst

<    1   2