Re: [PATCH] Avoid peeling in cunrolli

On Wed, 29 Nov 2017, Richard Biener wrote: > > It turns out that we don't vectorize the 2nd testcase in PR83202 > (or rather we do that in weird ways during BB vectorization) because > cunrolli decides to peel the inner loop completely based on > the size of the accessed arrays. That

Go patch committed: Don't make map zero value constant

This patch changes the Go frontend to not make the map zero value constant. The map zero value is a common symbol, and it doesn't really make sense to have a constant common symbol. Current GCC has started to reject this case, probably as part of the fix for PR 83100. Bootstrapped and ran Go

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

On 11/29/2017 04:13 PM, Segher Boessenkool wrote: This improves the assembler output (for -dp and -fverbose-asm) in several ways. It always prints the insn_cost. It does not print "[length = NN]" but "[c=NN l=NN]", to save space. It does not add one to the instruction alternative number

Re: [PATCH] PR libgcc/83112, Fix warnings on libgcc float128-ifunc.c

Hi, On Mon, Nov 27, 2017 at 06:40:09PM -0500, Michael Meissner wrote: > @@ -33,3 +35,13 @@ $(fp128_hw_obj) : $(srcdir)/config/rs6 > > $(fp128_ifunc_obj): INTERNAL_CFLAGS += $(FP128_CFLAGS_SW) > $(fp128_ifunc_obj): $(srcdir)/config/rs6000/t-float128-hw > + > +_mulkc3-hw.c:

Re: [PATCH] make canonicalize_condition keep its promise

On Tue, 2017-11-21 at 11:45 -0600, Aaron Sawdey wrote: > On Tue, 2017-11-21 at 10:06 -0700, Jeff Law wrote: > > On 11/20/2017 06:41 AM, Aaron Sawdey wrote: > > > On Sun, 2017-11-19 at 16:44 -0700, Jeff Law wrote: > > > > On 11/15/2017 08:40 AM, Aaron Sawdey wrote: > > > > > So, the story of this

Re: [C++ PATCH] Fix ICE on invalid std::tuple_size<...>::value (PR c++/83205)

On 11/29/2017 03:32 PM, Jakub Jelinek wrote: Hi! If tsize doesn't fit into uhwi, then it obviously can't match the number of identifiers in the structured binding declaration. While we could use compare_tree_int and avoid that way this conversion to uhwi (though, compare_tree_int does that

[committed] hppa-linux: Update baseline symbols

The attached patch updates the hppa-linux baseline symbols for gcc-8. Dave -- John David Anglin dave.ang...@bell.net 2017-11-29 John David Anglin * config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update. Index:

Re: [PING 2][PATCH] enhance -Wrestrict to handle string built-ins (PR 78918)

On 11/27/2017 05:44 AM, Richard Biener wrote: On Thu, Nov 16, 2017 at 10:29 PM, Martin Sebor wrote: Ping. I've fixed the outstanding false positive exposed by the Linux kernel. The kernel builds with four instances of the warning, all of them valid (perfect overlap in

Re: [PATCH][AArch64] Fix ICE due to store_pair_lanes

FYI: Here is a cut down test case showing the failure: int foo (void) { } extern void plunk (); int splat (void) {   static int once = 0;   plunk (, foo); } % obj/gcc/gcc/cc1 -mabi=ilp32 -O2 -quiet x.i during RTL pass: final x.i: In function ‘splat’: x.i:7:1: internal compiler error:

[PATCH] final: Improve output for -dp and -fverbose-asm

This improves the assembler output (for -dp and -fverbose-asm) in several ways. It always prints the insn_cost. It does not print "[length = NN]" but "[c=NN l=NN]", to save space. It does not add one to the instruction alternative number (everything else starts counting those at 0, too). And

[PATCH] combine: Print to dump if some insn cannot be combined into i3

Eventually we should print the reason that any combination fails. This is a good start (these happen often). Applying to trunk. Segher 2017-11-29 Segher Boessenkool * combine.c (try_combine): Print a message to dump file whenever I0, I1, or I2

[PATCH] combine: Do not throw away unneeded arms of parallels (PR83156)

The fix for PR82621 makes us not split an I2 if one of the results of those SETs is unused, since combine does not handle that properly. But this results in degradation for i386 (or more in general, for any target that does not have patterns for parallels with an unused result as a CLOBBER

[PATCH] Improve __builtin_mul_overflow (uns, 1U << y, ) (PR target/83210)

Hi! Even if target has an umulv4_optab pattern like i?86 mul[lq]; jo, if one argument is constant power of two, using two shifts, or for multiplication by 2 just shl with js on previous value is faster (though, for -Os mul[lq]; jo wins). Bootstrapped/regtested on x86_64-linux and i686-linux, ok

[PATCH] Riscv patterns to optimize away some redundant zero/sign extends.

This adds some new patterns to eliminate some unecessary zero/sign extends. This also adds one testcase for each pattern, and one testcase that works only with the rtx_costs change. There is a lot more work to be done here, but this does help. With a toolchain/linux kernel/busybox build, I see

[C++ PATCH] Fix ICE on invalid std::tuple_size<...>::value (PR c++/83205)

Hi! If tsize doesn't fit into uhwi, then it obviously can't match the number of identifiers in the structured binding declaration. While we could use compare_tree_int and avoid that way this conversion to uhwi (though, compare_tree_int does that anyway), for the normal uhwi case we have special

Re: [PATCH][AArch64] Fix ICE due to store_pair_lanes

On Wed, 2017-11-29 at 21:13 +0100, Christophe Lyon wrote: > Hi Wilco, > > This breaks the build of aarch64-none-elf toolchains: >  > /tmp/8868058_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/final.c:4564 > Please submit a full bug report, > with preprocessed source if appropriate. > Please

[PATCH] rs6000: Add second variant of adde

This adds a second variant of the adde insn pattern, this one with the CA register as the second operand. The existing pattern has it as the third operand. It would be ideal if RTL was always canonicalised like that, but it isn't (and that is not trivial), and this is a simple and harmless

patch to fix PR80818

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818 The patch was successfully tested and bootstrapped on x86_64. The patch has no test because it is hard to check the problem. I checked manually that the patch solves the problem on a test provided by Andreas

Re: [PR 82808] Use result types for arithmetic jump functions

On Tue, Nov 28 2017, Martin Jambor wrote: > ... > > Done, this is what I have just committed. I will prepare a conservative > fix for gcc 7 with only the expr_type_first_operand_type_p part. > The following is what I have committed to the gcc-7-branch after a round of bootstrap and testing on an

Re: [PATCH] C++: improve location of static_assert errors

OK. On Wed, Nov 29, 2017 at 4:26 PM, David Malcolm wrote: > Whilst investigating PR c++/82893 I noticed that the location > of static_assert diagnostics uses that of the "static_assert" > token, which seemed suboptimal to me, e.g.: > > error: non-constant condition for

Re: [PATCH] Add a warning for invalid function casts

On 10/09/2017 06:30 PM, Bernd Edlinger wrote: +/* Heuristic check if two parameter types can be considered ABI-equivalent. */ + +static bool +cxx_abi_equiv_type_p (tree t1, tree t2) This name is too general for a function that is specifically for implementing a particular warning. + if

Re: [PATCH][PR c++/82888] smarter code for default initialization of scalar arrays

On Fri, Nov 17, 2017 at 11:04 PM, Nathan Froyd wrote: > On Fri, Nov 17, 2017 at 8:50 AM, Jason Merrill wrote: >> On Thu, Nov 16, 2017 at 11:21 AM, Nathan Froyd wrote: >>> diff --git a/gcc/cp/init.c b/gcc/cp/init.c >>> index

[PATCH] C++: improve location of static_assert errors

Whilst investigating PR c++/82893 I noticed that the location of static_assert diagnostics uses that of the "static_assert" token, which seemed suboptimal to me, e.g.: error: non-constant condition for static assertion static_assert(sizeof(Baz) == 8, ""); ^ This patch

Re: [C++ Patch] PR 82293 ("[8 Regression] ICE in nonlambda_method_basetype at gcc/cp/lambda.c:886")

OK. On Wed, Nov 22, 2017 at 9:49 AM, Paolo Carlini wrote: > Hi, > > this ICE on valid is triggered by the existing cpp0x/lambda/lambda-ice20.C > when -Wshadow is requested. Today I confirmed that it can be reproduced only > after r251433, the "Reimplement handling of

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On Fri, Nov 24, 2017 at 8:31 AM, Marc Glisse wrote: > Hello, > > @@ -4247,9 +4248,20 @@ build_operator_new_call (tree fnname, vec va_gc> **args, > we disregard block-scope declarations of "operator new". */ >fns = lookup_function_nonclass (fnname, *args,

C++ PATCH for c++/82760, memory corruption with C++17 aligned new

Since build_operator_new_call expects to be able to adjust the arguments later in the function, we need to update *args with the actual arg vec we're using. Tested x86_64-pc-linux-gnu, applying to trunk. commit 08383aaa77a6a3f37dad598ec840028af43f04d9 Author: Jason Merrill

Re: [PATCH][AArch64] Fix ICE due to store_pair_lanes

On 28 November 2017 at 19:15, James Greenhalgh wrote: > On Mon, Nov 27, 2017 at 03:20:29PM +, Wilco Dijkstra wrote: >> The recently added store_pair_lanes causes ICEs in output_operand. >> This is due to aarch64_classify_address treating it like a 128-bit STR >>

Re: [patch] jump threading multiple paths that start from the same BB

On 11/27/2017 06:27 PM, Jeff Law wrote: On 11/07/2017 10:33 AM, Aldy Hernandez wrote: Without further ado, here are my monumental, earth shattering improvements: Conditional branches    Without patch: 411846839709    With    patch: 411831330316     %changed: -0.0037660% Number of

Re: [PATCH][i386,AVX] Enable VBMI2 support [7/7]

Hello Julia! On 24 Oct 10:28, Koval, Julia wrote: > Hi, > This patch enables VPSHRDV instruction. The doc for isaset and instruction: > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf > > Ok for trunk? Your patch is

Re: [PATCH][i386,AVX] Enable VBMI2 support [6/7]

Hello Julia, On 24 Oct 10:16, Koval, Julia wrote: > Hi, > This patch enables VPSHRDV instruction. The doc for isaset and instruction: > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf > > Ok for trunk? Your patch is

Add myself as GCC maintainer

Added myself as GCC maintainer with r255248: https://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00965.html thanks. Qing == ChangeLog +2017-11-29 Qing Zhao + + * MAINTAINERS (Write After Approval):

Re: RFC: Variable-length VECTOR_CSTs

Thanks for the quick feedback! Richard Biener writes: > On Wed, Nov 29, 2017 at 12:57 PM, Richard Sandiford > wrote: >> It was clear from the SVE reviews that people were unhappy with how >> "special" the variable-length case was. One

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On November 29, 2017 4:56:44 PM GMT+01:00, Martin Sebor wrote: >On 11/29/2017 01:30 AM, Jakub Jelinek wrote: >> On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: >>> On 11/27/2017 02:22 AM, Dominik Inführ wrote: Thanks for all the reviews! I’ve revised the

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On Wed, Nov 29, 2017 at 8:15 AM, David Malcolm wrote: > On Wed, 2017-11-29 at 08:56 -0700, Martin Sebor wrote: >> On 11/29/2017 01:30 AM, Jakub Jelinek wrote: >> > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: >> > > On 11/27/2017 02:22 AM, Dominik Inführ

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On Wed, 2017-11-29 at 08:56 -0700, Martin Sebor wrote: > On 11/29/2017 01:30 AM, Jakub Jelinek wrote: > > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: > > > On 11/27/2017 02:22 AM, Dominik Inführ wrote: > > > > Thanks for all the reviews! I’ve revised the patch, the > > > >

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On 11/29/2017 01:30 AM, Jakub Jelinek wrote: On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: On 11/27/2017 02:22 AM, Dominik Inführ wrote: Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag is now stored in tree_decl_with_vis (there already seem to be

Re: [PATCH] Fix PR tree-optimization/83195 testcase for arm

Hi Jakub, On 29/11/17 08:18, Jakub Jelinek wrote: Hi! The pr82929.c testcase uses store_merge effective target, which is int32plus && nonstrict_align. Unfortunately, arm is handled for nonstrict_align wierdly, although it has STRICT_ALIGNMENT 1, it is sometimes considered nonstrict_align (the

Re: RFC: Variable-length VECTOR_CSTs

On Wed, Nov 29, 2017 at 12:57 PM, Richard Sandiford wrote: > It was clear from the SVE reviews that people were unhappy with how > "special" the variable-length case was. One particular concern was > the use of VEC_DUPLICATE_CST and VEC_SERIES_CST, and the way that

Re: RFC: Variable-length VECTOR_CSTs

On Wed, 2017-11-29 at 11:57 +, Richard Sandiford wrote: [...] I can't really comment on the representation ideas, but I'm always happy to see new selftests... *** test_labels () > *** 13954,13959 > --- 14179,14350 > ASSERT_FALSE (FORCED_LABEL (label_decl)); > } >

[PATCH] Avoid peeling in cunrolli

It turns out that we don't vectorize the 2nd testcase in PR83202 (or rather we do that in weird ways during BB vectorization) because cunrolli decides to peel the inner loop completely based on the size of the accessed arrays. That unfortunately leaves exit tests in the outer loop body which in

[PATCH] Address SLP cost-model issue of PR83202

SLP costing and code generation has the very old issue that it operates on the SLP tree which, because it isn't a graph, contains redundancies. The following patch builds upon the hashing infrastructure I added a few months back and implements a workaround at code-generation and costing time

Re: [PATCH, i386] Fix movdi_internal to return MODE_TI with AVX512

On Wed, Nov 29, 2017 at 1:10 PM, Uros Bizjak wrote: > On Wed, Nov 29, 2017 at 12:05 PM, Shalnov, Sergey > wrote: >> Hi, >> I found wrong MODE_XI used in movdi_internal that cause zmm >> Generation with "-march=skylake-avx512 -mprefer-vector-width=128"

Re: [PATCH, i386] Fix movdi_internal to return MODE_TI with AVX512

On Wed, Nov 29, 2017 at 12:05 PM, Shalnov, Sergey wrote: > Hi, > I found wrong MODE_XI used in movdi_internal that cause zmm > Generation with "-march=skylake-avx512 -mprefer-vector-width=128" > options set. This patch fixes the mode and register type but keep using >

RFC: Variable-length VECTOR_CSTs

It was clear from the SVE reviews that people were unhappy with how "special" the variable-length case was. One particular concern was the use of VEC_DUPLICATE_CST and VEC_SERIES_CST, and the way that that would in turn lead to different representations of VEC_PERM_EXPRs with constant permute

[PATCH, i386] Fix movdi_internal to return MODE_TI with AVX512

Hi, I found wrong MODE_XI used in movdi_internal that cause zmm Generation with "-march=skylake-avx512 -mprefer-vector-width=128" options set. This patch fixes the mode and register type but keep using AVX512 instruction set. 2017-11-28 Sergey Shalnov gcc/ *

Re: [PATCH GCC]Rename and make remove_dead_inserted_code a simple dce interface

On Wed, Nov 29, 2017 at 10:02 AM, Richard Biener wrote: > On Tue, Nov 28, 2017 at 3:48 PM, Bin Cheng wrote: >> Hi, >> This patch renames remove_dead_inserted_code to simple_dce_from_worklist, >> moves it to tree-ssa-dce.c >> and makes it a simple

Re: [Ping][PATCH v3] Fix Incorrect ASan global variables alignment on arm (PR sanitizer/81697)

On Tue, Nov 28, 2017 at 10:04:51AM +0300, Maxim Ostapenko wrote: > (CC'ing Jakub and Ramana) > > I would like to ping the following patch: > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02288.html > Fix Incorrect ASan global variables alignment on arm (PR sanitizer/81697) > > -Maxim >

Re: [PATCH v3 1/4] [SPARC] Errata workaround for GRLIB-TN-0012

> 2017-11-17 Daniel Cederman > > * config/sparc/sparc.c (fpop_insn_p): New function. > (sparc_do_work_around_errata): Insert NOP instructions to > prevent sequences that could trigger the TN-0012 errata for > GR712RC. >

Re: [PATCH GCC]Rename and make remove_dead_inserted_code a simple dce interface

On Tue, Nov 28, 2017 at 3:48 PM, Bin Cheng wrote: > Hi, > This patch renames remove_dead_inserted_code to simple_dce_from_worklist, > moves it to tree-ssa-dce.c > and makes it a simple public DCE interface. Bootstrap and test along with > loop interchange. It's required >

Re: (patch, fortran] PR83021 - [7/8 Regression] gfortran segfault in polymorphic assignment

Committed to 7-branch and trunk and r255205 and r255202 respectively. Paul On 26 November 2017 at 18:40, Paul Richard Thomas wrote: > Dear All, > > This regression was caused by the patch for PR81447. The chunk that > has been modified came about because use

[Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

This problem is not really a regression but is a "feature" that was exposed by my patch for PR81447. The testcase fails because the caf token for the pointer component is not present in the type. This is fixed in trans-types.c (gfc_get_derived_type) in the manner described in the ChangeLog.

Re: [PATCH] Implement std::to_address for C++2a

(Also added a new [_neg] test) Move static_assert for function pointers to __to_address 2017-11-28 Glen Joseph Fernandes * include/bits/ptr_traits.h (to_address): Moved static_assert. * testsuite/20_util/to_address/1_neg.cc: New test. Tested

Re: [Patch][x86, backport] Backport to GCC-6 vzeroupper patches

On Wed, Nov 29, 2017 at 10:46 AM, Peryt, Sebastian wrote: > Hi, > > I'd like to ask for backporting to GCC-6 branch vzeroupper generation patches > from trunk, > that are resolving 3 PRs: > PR target/82941 > PR target/82942 > PR target/82990 > > Two patches were

Re: [Patch][x86, backport] Backport to GCC-7 vzeroupper patches

On Wed, Nov 29, 2017 at 10:39 AM, Peryt, Sebastian wrote: > Hi, > > I'd like to ask for backporting to GCC-7 branch vzeroupper generation patches > from trunk, > that are resolving 3 PRs: > PR target/82941 > PR target/82942 > PR target/82990 > > Two patches were

[Patch][x86, backport] Backport to GCC-6 vzeroupper patches

Hi, I'd like to ask for backporting to GCC-6 branch vzeroupper generation patches from trunk, that are resolving 3 PRs: PR target/82941 PR target/82942 PR target/82990 Two patches were combined into one and rebased. Bootstraped and tested. Is it ok for merge? Changelog: Fix PR82941 and

Re: [PATCH] Improve build_simple_mem_ref_loc (PR middle-end/83185)

On Wed, 29 Nov 2017, Jakub Jelinek wrote: > Hi! > > This PR is about forwprop propagating: > _17 = __builtin_alloca_with_align (_16, 256); > _18 = _17 + 32; > __builtin___asan_alloca_poison (_18, _8); > _7 = &*_18[4]; > __builtin_va_start (_7, 0); > to: > _17 =

Re: [PATCH] Improve seq_cost (PR middle-end/80929)

On Wed, 29 Nov 2017, Jakub Jelinek wrote: > Hi! > > This PR complains that seq_cost counts all non-single_set insns as 1 > unconditionally, which is indeed bad. For some like compare + arithmetics > we even have now code in pattern_cost that handles those reasonably by > default, for others

[Patch][x86, backport] Backport to GCC-7 vzeroupper patches

Hi, I'd like to ask for backporting to GCC-7 branch vzeroupper generation patches from trunk, that are resolving 3 PRs: PR target/82941 PR target/82942 PR target/82990 Two patches were combined into one and rebased. Bootstraped and tested. Is it ok for merge? Changelog: Fix PR82941 and

Re: [PATCH] complex type canonicalization

On Wed, Nov 29, 2017 at 10:33:04AM +0100, Jakub Jelinek wrote: > > - /* We need to create a name, since complex is a fundamental type. */ > > - if (!TYPE_NAME (t) && named) > > + /* We need to create a name, since complex is a fundamental type. */ > > + if (named) > > + { > > +

Re: [PATCH] complex type canonicalization

On Tue, Nov 28, 2017 at 01:27:54PM -0500, Nathan Sidwell wrote: > --- tree.c(revision 255202) > +++ tree.c(working copy) > - /* We need to create a name, since complex is a fundamental type. */ > - if (!TYPE_NAME (t) && named) > + /* We need to create a name, since complex is a

Re: [PATCH] Fix vec_concatv2di pattern for SSE4 (PR target/80819)

On Wed, Nov 29, 2017 at 9:24 AM, Jakub Jelinek wrote: > Hi! > > Before r218303 we had just (=x,0,rm) alternative for SSE4 (no AVX), > that change turned it into (=Yr,0,*rm) and (=*x,0,rm) alternatives, > so that we avoid too many prefixes if possible. > The latter alternative is

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: > On 11/27/2017 02:22 AM, Dominik Inführ wrote: > > Thanks for all the reviews! I’ve revised the patch, the > > operator_delete_flag is now stored in tree_decl_with_vis (there already > > seem to be some FUNCTION_DECL-flags in there).

[PATCH] Fix vec_concatv2di pattern for SSE4 (PR target/80819)

Hi! Before r218303 we had just (=x,0,rm) alternative for SSE4 (no AVX), that change turned it into (=Yr,0,*rm) and (=*x,0,rm) alternatives, so that we avoid too many prefixes if possible. The latter alternative is fine, we want the *, because that is the point, Yr class is the subset of x

[PATCH] Fix PR tree-optimization/83195 testcase for arm

Hi! The pr82929.c testcase uses store_merge effective target, which is int32plus && nonstrict_align. Unfortunately, arm is handled for nonstrict_align wierdly, although it has STRICT_ALIGNMENT 1, it is sometimes considered nonstrict_align (the only exception apparently). Now, the testcase

[PATCH] Improve build_simple_mem_ref_loc (PR middle-end/83185)

Hi! This PR is about forwprop propagating: _17 = __builtin_alloca_with_align (_16, 256); _18 = _17 + 32; __builtin___asan_alloca_poison (_18, _8); _7 = &*_18[4]; __builtin_va_start (_7, 0); to: _17 = __builtin_alloca_with_align (_16, 256); _18 = _17 + 32;

[PATCH] Improve seq_cost (PR middle-end/80929)

Hi! This PR complains that seq_cost counts all non-single_set insns as 1 unconditionally, which is indeed bad. For some like compare + arithmetics we even have now code in pattern_cost that handles those reasonably by default, for others targets have the option through a hook to return whatever