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

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] >

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

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 :

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

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. >

Backport of r244010 to gcc-6-branch

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] Fix multi-versioning issues (PR ipa/80732).

On 06/19/2017 12:35 PM, Jan Hubicka wrote: >> Hello. >> >> Following patch tries to resolve following 2 issues: >> >> a) When one takes address of a function that uses target_clones attribute, >>default implementation is always returned. >> >> b) Using dlsym("foo") should work and thus the

Re: [PATCH GCC][08/13]Refactoring structure partition for distribution

On Wed, Jun 14, 2017 at 2:47 PM, Richard Biener wrote: > On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >> Hi, >> This patch refactors struct partition for later distribution. It records >> bitmap of data references in struct partition rather

Re: [Neon intrinsics] Literal vector construction through vcombine is poor

On 16/06/17 22:08, Michael Collison wrote: > This patch improves code generation for literal vector construction by > expanding and exposing the pattern to rtl optimization earlier. The current > implementation delays splitting the pattern until after reload which results > in poor code

[rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

Many parallel set insns are of the form of a single set that also sets the condition code flags. In this case the cost of such an insn is normally the cost of the part that doesn't set the flags, since updating the condition flags is simply a side effect. At present all such insns are treated as

[PATCH] ASAN: handle addressable params (PR sanitize/81040).

Hi. Following patch addresses issue where we have a function argument which address is taken and -fsanitize=address does not wrap up the argument with red zone. It's done in sanopt pass, where I create a new automatic variable which is used in the function instead of the original argument. Patch

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

Hi! On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote: > Many parallel set insns are of the form of a single set that also sets > the condition code flags. In this case the cost of such an insn is > normally the cost of the part that doesn't set the flags, since updating >

[PR c++/81119] Wshadow regression

This fixes pr 81119. My rewriting of name lookup was a little too eager to warn about constructor hiding. This restores the earlier behaviour of only warning when hiding via a function. nathan -- Nathan Sidwell 2017-06-19 Nathan Sidwell PR c++/81119 * name-lookup.c

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On 19/06/17 15:08, Segher Boessenkool wrote: > Hi! > > On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote: >> Many parallel set insns are of the form of a single set that also sets >> the condition code flags. In this case the cost of such an insn is >> normally the cost of

Re: [PATCH] Initialize live_switch_vars for SWITCH_BODY == STATEMENT_LIST (PR sanitizer/80879).

On Fri, May 26, 2017 at 01:05:28PM +0200, Martin Liška wrote: > Hello. > > Unfortunately I guarded use-after-scope to track live switch variables just > to BIND_EXPR. However the bind expression can be included in a STATEMENT_LIST. > That enables proper tracking and fixes the test added. > >

Re: [PATCH] ASAN: handle addressable params (PR sanitize/81040).

On Mon, Jun 19, 2017 at 03:50:42PM +0200, Martin Liška wrote: > @@ -858,6 +862,117 @@ sanitize_asan_mark_poison (void) > } > } > Missing function comment. > +static tree > +rewrite_usage_of_param (tree *op, int *walk_subtrees, void *data) > +{ > + struct walk_stmt_info *wi = (struct

Re: [PATCH] Fix PR81112

On Mon, Jun 19, 2017 at 09:16:58AM +0200, Richard Biener wrote: > > The following fixes an ommision in find_constructor_constant_at_offset > to handle RANGE_EXPR in array constructor indices. The handling is > conservative in that it only handles the first index in the range. > > Bootstrapped

Re: [PATCH] Fix yet another -fsanitize=undefined ubsan_encode_value ICE (PR sanitizer/81125)

On Mon, 19 Jun 2017, Jakub Jelinek wrote: > Hi! > > And here is another ICE. While we have a current_function_decl > in this case, still create_tmp_var's called gimple_add_tmp_var > and mark_addressable don't work too well when the current function > is a C++ ctor or dtor that the FE then

[PATCH] Fix PR81118

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-06-19 Richard Biener PR middle-end/81118 * tree-cfgcleanup.c (cleanup_tree_cfg_noloop): Clear niter estimates if we changed anything. * gcc.dg/torture/pr81118.c:

Re: [PR target/25111] New patterns for m68k bit insns

On Nov 19 2016, Jeff Law wrote: > diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md > index 7b7f373..2085619 100644 > --- a/gcc/config/m68k/m68k.md > +++ b/gcc/config/m68k/m68k.md > @@ -5336,6 +5336,45 @@ > } >[(set_attr "type" "bitrw")]) > > +(define_insn

Re: [PATCH GCC][06/13]Preserve loop nest in whole distribution life time

On Tue, Jun 13, 2017 at 12:08 PM, Richard Biener wrote: > On Tue, Jun 13, 2017 at 1:06 PM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote: >>> Hi, >>> This simple patch computes and preserves

[PATCH] Fix -fsanitize=undefined ubsan_encode_value ICE (PR sanitizer/81111)

Hi! Martin's recent patch that introduced sanitize_flags_p causes us to instrument operations even when current_function_decl is NULL. If it is valid constant expression it will be folded away soon, otherwise usually we emit a runtime initializer in the static ctors function for it. In any

Re: [PATCH GCC][09/13]Simply cost model merges partitions with the same references

On Wed, Jun 14, 2017 at 2:54 PM, Richard Biener wrote: > On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >> Hi, >> Current primitive cost model merges partitions with data references sharing >> the same >> base address. I believe it's designed

[PATCH] Fix yet another -fsanitize=undefined ubsan_encode_value ICE (PR sanitizer/81125)

Hi! And here is another ICE. While we have a current_function_decl in this case, still create_tmp_var's called gimple_add_tmp_var and mark_addressable don't work too well when the current function is a C++ ctor or dtor that the FE then duplicates. Fixed by telling ubsan_encode_value whether it

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19/06/17 15:31, Christophe Lyon wrote: On 19 June 2017 at 16:11, Thomas Preudhomme wrote: On 19/06/17 10:16, Thomas Preudhomme wrote: On 19/06/17 08:41, Christophe Lyon wrote: Hi Thomas, On 15 June 2017 at 18:18, Thomas Preudhomme

Re: [PATCH GCC][06/13]Preserve loop nest in whole distribution life time

On Mon, Jun 19, 2017 at 3:32 PM, Bin.Cheng wrote: > On Tue, Jun 13, 2017 at 12:08 PM, Richard Biener > wrote: >> On Tue, Jun 13, 2017 at 1:06 PM, Richard Biener >> wrote: >>> On Mon, Jun 12, 2017 at 7:02 PM, Bin

Re: [PATCH GCC][07/13]Preserve data references for whole distribution life time

On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener wrote: > On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote: >> Hi, >> This patch collects and preserves all data references in loop for whole >> distribution life time. It will be used afterwards. >>

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19/06/17 10:16, Thomas Preudhomme wrote: On 19/06/17 08:41, Christophe Lyon wrote: Hi Thomas, On 15 June 2017 at 18:18, Thomas Preudhomme wrote: Hi, Conditions checked for ARM targets in vector-related effective targets are inconsistent: * sometimes

[C++ PATCH] small pt.c cleanup

I discovered a cleanup I'd forgotten about. The only unobvious thing about this patch is that just before the second hunk we've already set DECL_RTL to NULL. No need to do it twice. nathan -- Nathan Sidwell 2017-06-19 Nathan Sidwell * pt.c (coerce_template_parms): Fix

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19 June 2017 at 16:11, Thomas Preudhomme wrote: > > > On 19/06/17 10:16, Thomas Preudhomme wrote: >> >> >> >> On 19/06/17 08:41, Christophe Lyon wrote: >>> >>> Hi Thomas, >>> >>> >>> On 15 June 2017 at 18:18, Thomas Preudhomme >>>

Re: [PATCH] Fix -fsanitize=undefined ubsan_encode_value ICE (PR sanitizer/81111)

On Mon, 19 Jun 2017, Jakub Jelinek wrote: > Hi! > > Martin's recent patch that introduced sanitize_flags_p causes us to > instrument operations even when current_function_decl is NULL. If it > is valid constant expression it will be folded away soon, otherwise > usually we emit a runtime

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On 19/06/17 15:08, Segher Boessenkool wrote: > Hi! > > On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote: >> Many parallel set insns are of the form of a single set that also sets >> the condition code flags. In this case the cost of such an insn is >> normally the cost of

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On Mon, Jun 19, 2017 at 03:28:20PM +0100, Richard Earnshaw (lists) wrote: > > That's not what combine does: it optimistically assumes any combination > > with unknown costs is an improvement. > > So try this testcase on ARM. > > unsigned long x, y, z; > int b; > void test() > { >b =

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On Mon, Jun 19, 2017 at 03:45:23PM +0100, Richard Earnshaw (lists) wrote: > >> At present all such insns are treated as having unknown cost (ie 0) and > >> combine assumes that such insns are infinitely more expensive than any > >> other insn sequence with a non-zero cost. > > > > That's not what

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

On Jun 14, 2017, at 5:30 AM, Thomas Preudhomme wrote: > > 2017-06-14 Thomas Preud'homme > > * dg-cmp-results.sh: Keep test result lines rather than throwing > header and summary to support sum files with multiple tools.

[PATCH] Ping of ccmp.c (conditional compare) patch

This is a re-ping of: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html It was pointed out to me that my original subject line [PATCH/AARCH64] might be misleading since the patch is not to code in config/aarch64. It is to ccmp.c which is in the shared gcc directory. That said,

Add dg-add-options feature stack_size

[ was: Re: [PATCH, testsuite] Add effective target stack_size ] On 06/09/2017 05:25 PM, Mike Stump wrote: On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote: this patch adds effective target stack_size. OK for trunk if x86_64 and nvptx testing succeeds? Ok. Hi, I came

Re: [PATCH GCC][09/13]Simply cost model merges partitions with the same references

On Mon, Jun 19, 2017 at 3:40 PM, Bin.Cheng wrote: > On Wed, Jun 14, 2017 at 2:54 PM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >>> Hi, >>> Current primitive cost model merges partitions with

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

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 (match_operand:MODEF 0 "register_operand") + [(set (match_operand:MODEF

Re: [PATCH GCC][07/13]Preserve data references for whole distribution life time

On Mon, Jun 19, 2017 at 4:16 PM, Richard Biener wrote: > On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote: >> On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener >> wrote: >>> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng

Re: [PATCH GCC][07/13]Preserve data references for whole distribution life time

On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote: > On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote: >>> Hi, >>> This patch collects and preserves all data

Re: [PATCH, testsuite] Add effective target stack_size

On Jun 19, 2017, at 2:21 AM, Christophe Lyon wrote: > > The attached patch removes the support for STACK_SIZE in the testcase > as you suggested, and it works fine (cross-tested on aarch64/arm targets) > > OK for trunk? Ok.

RFC: stack/heap collision vulnerability and mitigation with GCC

As some of you are likely aware, Qualys has just published fairly detailed information on using stack/heap clashes as an attack vector. Eric B, Michael M -- sorry I couldn't say more when I contact you about -fstack-check and some PPC specific stuff. This has been under embargo for the last

Re: [PATCH GCC][08/13]Refactoring structure partition for distribution

On Mon, Jun 19, 2017 at 3:37 PM, Bin.Cheng wrote: > On Wed, Jun 14, 2017 at 2:47 PM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >>> Hi, >>> This patch refactors struct partition for later

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On 19/06/17 16:09, Segher Boessenkool wrote: > On Mon, Jun 19, 2017 at 03:45:23PM +0100, Richard Earnshaw (lists) wrote: At present all such insns are treated as having unknown cost (ie 0) and combine assumes that such insns are infinitely more expensive than any other insn sequence

Re: [Patch ARM] Fix PR71778

On Fri, Jun 16, 2017 at 11:07:41AM +0100, Kyrill Tkachov wrote: > > On 16/06/17 10:07, James Greenhalgh wrote: > >On Wed, Jun 14, 2017 at 11:21:30AM +0100, Kyrill Tkachov wrote: > > > > <...> > > > >>That movv2di expander is the one in vec-common.md that ends up calling > >>neon_make_constant.

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

On 06/11/2017 07:34 PM, Xi Ruoyao wrote: This patch adds warning option -Wstring-plus-char for C/C++. +void +warn_if_string_plus_char (location_t loc, tree ptrtype, tree inttype) +{ + if (POINTER_TYPE_P (ptrtype) + && type_main_variant_is_char (TREE_TYPE (ptrtype)) + &&

Re: [Patch ARM] Fix PR71778

On 19/06/17 17:16, James Greenhalgh wrote: On Fri, Jun 16, 2017 at 11:07:41AM +0100, Kyrill Tkachov wrote: On 16/06/17 10:07, James Greenhalgh wrote: On Wed, Jun 14, 2017 at 11:21:30AM +0100, Kyrill Tkachov wrote: <...> That movv2di expander is the one in vec-common.md that ends up

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

On 06/11/2017 07:39 PM, Xi Ruoyao wrote: This patch adds document of -Wstring-plus-int and -Wstring-plus-char. +@item -Wstring-plus-char +@opindex Wstring-plus-char +@opindex Wno-string-plus-char +Warn for adding a character to a string pointer, which seems like a failed +attempt to append to

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

On 06/11/2017 07:26 PM, Xi Ruoyao wrote: Hi, I've implemented -Wstring-plus-int and -Wstring-plus-char (like their counterpart in Clang) for GCC. From the Clang patch(*) it only "warns when a character literal is added (using '+') to a variable with type 'char *' (or any other pointer to

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

On 06/11/2017 07:32 PM, Xi Ruoyao wrote: This patch adds warning option -Wstring-plus-int for C/C++. gcc/ChangeLog: 2017-06-12 Xi Ruoyao * c-family/c.opt: New option -Wstring-plus-int. * c-family/c-common.c (pointer_int_sum): Checking for

[PATCH] Fix UB in tree-chkp.c

Hi! bootstrap-ubsan shows a couple of: ../../gcc/tree-chkp.c:694:37: runtime error: shift exponent 63 is too large for 32-bit type 'int' errors. 1 << (TYPE_PRECISION (ptr_type_node) - 1) should have been obviously HOST_WIDE_INT_1U << (TYPE_PRECISION (ptr_type_node) - 1) but even then, it is 1)

Re: [PATCH] Fix UB in tree-ssa-structalias.c

On June 19, 2017 7:46:03 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >Another easy to fix bug reported by bootstrap-ubsan. >We check that rhsunitoffset fits into shwi, but even if it does, >8x that might not, in which case we trigger UB. >Fixed by doing the multiplication in

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

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 > page without probing the page. There's a platform ABI issue here. At least some kernel fixes for these stack

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

On Mon, Jun 19, 2017 at 05:50:56PM +, 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 > > page without probing the page. > > There's

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

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 need to implement >> allocation and probing via a "moving sp" strategy. Probing into >> unallocated

Re: [patch, libfortran] Speed up cshift for dim > 1

Hi Dominique, For the record, the following CSHIFT is still 4 times slower than the DO loop I have looked into this a bit. The main reason is that, unlike cshift0 (without the array as shift) we do not generate individual functions to call for the usual data types, we use memcpy with a size

Re: [PATCH] Fix UB in tree-chkp.c

2017-06-19 20:43 GMT+03:00 Jakub Jelinek : > Hi! > > bootstrap-ubsan shows a couple of: > ../../gcc/tree-chkp.c:694:37: runtime error: shift exponent 63 is too large > for 32-bit type 'int' > errors. > > 1 << (TYPE_PRECISION (ptr_type_node) - 1) > should have been obviously >

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

Out of curiousity, does the old Alpha/VMS stack-checking API meet the requirements? From what I recall, I think it does.

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

On 06/19/2017 07:50 PM, Joseph Myers wrote: > There's a platform ABI issue here. At least some kernel fixes for these > stack issues, as I understand it, increase the size of the stack guard to > more than a single page. It would be possible to define the ABI to > require such a larger guard

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

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: > > > > 2017-06-12  Xi Ruoyao   > > > > * c-family/c.opt: New option -Wstring-plus-int. >

C++ PATCH for c++/81073, constexpr and static var in statement-expression

The testcase successfully compiles, but then fails to link because we've optimized away the declaration of the variable. We catch this in potential_constant_expression_1, but this path wasn't calling it. Fixed on trunk by always calling that function, not just in templates. With that change, I

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

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 $0, (%rsp) > > or movl $0, (%esp) ? > Florian

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

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 need to

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

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... On x86-64, PUSH REG is just a single byte, so for

Re: Add dg-add-options feature stack_size

On Jun 19, 2017, at 10:11 AM, Tom de Vries wrote: > > I came across dg-add-options, and wondered if adding a dg-add-options feature > stack_size is a better way to make STACK_SIZE available. I don't have a strong opinion here, but, it does look a tad simpler and nicer.

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On Mon, Jun 19, 2017 at 05:01:10PM +0100, Richard Earnshaw (lists) wrote: > Yeah, and I'm not suggesting we change the logic there (sorry if the > description was misleading). Instead I'm proposing that we handle more > cases for parallels to not return zero. Right. My test run is half way

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

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 $0, (%rsp) > or movl $0, (%esp) ? Florian raised this privately to me as well. THere's a couple issues. 1. Is

[PATCH] Fix UB in tree-ssa-structalias.c

Hi! Another easy to fix bug reported by bootstrap-ubsan. We check that rhsunitoffset fits into shwi, but even if it does, 8x that might not, in which case we trigger UB. Fixed by doing the multiplication in unsigned HWI type to make it well defined. Bootstrapped/regtested on x86_64-linux and

Forward list default default and move constructors

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

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

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 -

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

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

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

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: 2017-06-12 Xi Ruoyao * c-family/c.opt: New option

[PATCH][AArch64] Mark symbols as constant

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 SPEC2006). int x0 = 1, x1 = 2, x2 = 3; int f (int x,

[PR c++/81124] inline namespace checking

This fixes 81124, where we used ovl_iterate to iterate over a lookup result. We should always use lkp_iterate in those circumstances. However, regular lookup is not what we want here. We don't want to follow using directives -- just look in the local inline hierarchy. Plus also ignore decls

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

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

On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote: > After much poking around I concluded that we really need to implement > allocation and probing via a "moving sp" strategy. Probing into > unallocated areas runs afoul of valgrind, so that's a non-starter. > > Allocating stack space,

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

On 2017-06-19 10:30 -0600, Martin Sebor wrote: > On 06/11/2017 07:34 PM, Xi Ruoyao wrote: > > This patch adds warning option -Wstring-plus-char for C/C++. > > > > +void > +warn_if_string_plus_char (location_t loc, tree ptrtype, tree inttype) > +{ > +  if (POINTER_TYPE_P (ptrtype) > +  &&

[RFC PATCH] -fsanitize=pointer-overflow support (PR sanitizer/80998)

Hi! The following patch adds -fsanitize=pointer-overflow support, which adds instrumentation (included in -fsanitize=undefined) that checks that pointer arithmetics doesn't wrap. If the offset on ptr p+ off when treating it as signed value is non-negative, we check whether the result is bigger

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

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 >> page without probing the page. > > There's a platform ABI issue

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

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

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

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

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

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

> > 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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Re: [PATCH rs6000] Fix for commit 249311

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

Re: [PATCH, testsuite] Add effective target stack_size

On 12 June 2017 at 16:28, Tom de Vries wrote: > On 06/12/2017 02:28 PM, Christophe Lyon wrote: >> >> Hi Tom, >> >> On 9 June 2017 at 17:25, Mike Stump wrote: >>> >>> On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote:

[testsuite] Remove reference to Solaris 2.[56]

I happened to notice that we have one last reference to long obsolete Solaris versions in the testsuite. Fixed like this, tested with the appropriate runtest invocation on i386-pc-solaris2.12, installed on mainline. Rainer --

Add quality tracking for profile counter

Hi, this patch makes us to track quality of the profile. This is useful to disable some agressive optimizations when counts are known to be unreliable. Bootstrapped/regtested x86_64-linux, Honza * profile-count.c (profile_count::dump): Dump quality.

Re: [PATCH] PR libstdc++/81092 add std::wstring symbols and bump library version

On 19/06/17 11:18 +0200, Rainer Orth wrote: Hi Jonathan, On 14/06/17 19:13 +0100, Jonathan Wakely wrote: There are two symbols defined in GCC 7.1's libstdc++.6.0.23 library which are not exported on all targets (because I wrote "m" in the linker script instead of "[jmy]"). This patch bumps

Re: C/C++ PATCH to implement -Wmultistatement-macros (PR c/80116)

On Tue, Jun 13, 2017 at 03:29:32PM +, Joseph Myers wrote: > On Tue, 13 Jun 2017, Marek Polacek wrote: > > > * c-parser.c (c_parser_if_body): Set the location of the > > body of the conditional after parsing all the labels. Call > > warn_for_multistatement_macros. > >

Re: Prevent infinite recursion between simplification and CSE in FRE

On Mon, 19 Jun 2017, Richard Biener wrote: On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse wrote: Hello, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the context. FRE can go into an infinite recursion with some match.pd simplifications (that have been

Re: [PATCH] Initialize live_switch_vars for SWITCH_BODY == STATEMENT_LIST (PR sanitizer/80879).

PING^2 On 06/06/2017 08:58 AM, Martin Liška wrote: > PING^1 > > On 05/26/2017 01:05 PM, Martin Liška wrote: >> Hello. >> >> Unfortunately I guarded use-after-scope to track live switch variables just >> to BIND_EXPR. However the bind expression can be included in a >> STATEMENT_LIST. >> That

  1   2   >