Re: [PATCH] [AArch64] Implement popcount pattern

On Fri, Feb 03, 2017 at 06:57:54AM +, Hurugalawadi, Naveen wrote: > Hi Andrew, > > Thanks for clearing the confusion. > > > I don't understand this comment and how it relates to your updated patch > > foo, foo1 and foo2 generates calls to "popcountdi2" which should have > been "popcountsi2"

[committed] Fix gfortran.dg/coarray_43.f90 on hppa*-*-hpux*

We need to link against libatomic when available. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2017-02-03 John David Anglin * gfortran.dg/coarray_43.f90: Add "-latomic" option if libatomic_available. Index:

[committed] Require alias support for gcc.dg/pr77587.c

This avoids test failure on 32-bit hppa*-*-hpux*. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2017-02-03 John David Anglin * gcc.dg/pr77587.c: Require alias support. * gcc.dg/pr77587a.c: Likewise. Index: gcc.dg/pr77587.c

[committed] Skip tests on hppa*-*-hpux*

The attached change skips a couple of tests on hpux. The 32-bit hppa-hpux target lacks support for the dwarf debug format. We also lack the %hhd format except on 11.31. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2017-02-03 John David Anglin

[committed] Fix some more tests that fail on hppa*-*-hpux* due to limited common alignment

The attached change adds the -fno-common option to several tests that fail on hppa*-*-hpux*. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2017-02-03 John David Anglin * c-c++-common/Wunused-var-15.c: Add -fno-common additional option

Re: [wwwdocs, coding conventions] Mention OVERRIDE/FINAL

On Fri, Feb 03, 2017 at 09:34:52AM +0100, Gerald Pfeifer wrote: > On Fri, 14 Oct 2016, David Malcolm wrote: > > On Fri, 2016-10-14 at 16:27 +0100, Pedro Alves wrote: > >> FYI, I pushed these in now. I also bootstrapped with the > >> jit included in the selected languages, and hacked the > >> jit

[committed] Add gcc/function-tests.o to compare_exclusions for 32-bit hppa*-*-hpux*.

Depending on the bootstrap compiler and configure options, we sometimes get a compare failure for gcc/function-tests.o on 32-bit hppa*-*-hpux*. The problem is a "_GLOBAL__F_" label containing a "random" string. For example, .EXPORT

Re: [PATCH] sched: Do not move expensive insns speculatively (PR68664)

Hi Jeff, On Fri, Feb 03, 2017 at 04:31:58PM -0700, Jeff Law wrote: > >+@deftypefn {Target Hook} bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn > >*@var{insn}) > >+Some instructions should never be speculated by the schedulers, usually > >+ because the instruction is too expensive to get this

Re: [PATCH] PR target/66144, PowerPC improve vector compare

On Fri, Feb 03, 2017 at 06:07:56PM -0600, Segher Boessenkool wrote: > On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote: > > +;; Return 1 if operand is either a vector constant of all 0 bits of a > > vector > > +;; constant of all 1 bits. > > +(define_predicate

Re: [PATCH, rs6000] gcc 5 back port of vec_packs and vec_vgbbd builtin table entry fixes

On Fri, Feb 03, 2017 at 02:23:12PM -0800, Carl E. Love wrote: > The GCC 6 branch for the back port of the following two mainline commits > was approved and committed to GCC 6. The following patch is the back > port for the two commits for the GCC 5 branch. The only difference > relative to the

Re: [PATCH] PR target/66144, PowerPC improve vector compare

On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote: > +;; Return 1 if operand is either a vector constant of all 0 bits of a vector > +;; constant of all 1 bits. > +(define_predicate "vector_int_same_bit" > + (match_code "const_vector") > +{ > + if (GET_MODE_CLASS (mode) !=

Re: PR79286, ira combine_and_move_insns in loops

On 02/02/2017 02:31 AM, Alan Modra wrote: Revised patch that cures the lra related -m32 -Os regression too. The code that I'm patching here is changing a REG_EQUAL note to REG_EQUIV, ie. asserting that the value of the reg is always the value set by the current instruction. Which is not always

Re: [PATCH] sched: Do not move expensive insns speculatively (PR68664)

On 02/03/2017 01:12 PM, Segher Boessenkool wrote: Scheduling should never move very expensive instructions to places they are executed more frequently. This patch fixes that, reducing the execution time of c-ray by over 40% (I tested on a BE Power7 system). This introduces a new target hook

Re: [PATCH] Fix improper combiner optimization of mixed mode vector/scalar expressions (PR 79365)

Hi, A couple of things. Firstly, we are in stage 4 now, so unless this is a regression it will have to wait for GCC 8. I can carry the patch or you can repost it when we are in stage 1. Secondly, you forgot the changelog. On Fri, Feb 03, 2017 at 03:03:06PM -0500, Walter Lee wrote: > In

Re: [PATCH] Fix memory leak in parloops (PR tree-optimization/79338)

On 02/03/2017 03:27 PM, Jakub Jelinek wrote: Hi! On the gcc.dg/autopar/outer-4.c testcase we leak memory, because vect_analyze_loop_form allocates vinfos for all the stmts in the loop and when it calls vect_analyze_loop_form on the loop->inner before the former is destroyed, we overwrite all

C++ PATCH for c++/78689 (ICE on constructor with label)

My patch for the new inheriting constructor semantics changed tree-inline.c to avoid copying non-taken branches, in order to avoid trying to refer to parameters that are omitted from base constructor clones; this overlooked that we might enter such branches via goto. This patch reverts that

Re: [PATCH] Fix memory leak in the vectorizer (PR tree-optimization/79340)

On 02/03/2017 03:24 PM, Jakub Jelinek wrote: Hi! As mentioned in the PR, on the gfortran.dg/forall_7.f90 testcase we leak memory starting with r239542. vect_get_slp_defs allocates a vector of vectors, elements corresponding to NULL in slp_ops are .create (0) vectors that don't need freeing,

[PATCH] Fix memory leak in parloops (PR tree-optimization/79338)

Hi! On the gcc.dg/autopar/outer-4.c testcase we leak memory, because vect_analyze_loop_form allocates vinfos for all the stmts in the loop and when it calls vect_analyze_loop_form on the loop->inner before the former is destroyed, we overwrite all those vinfo pointers for stmts inside of the

[PATCH] Fix memory leak in the vectorizer (PR tree-optimization/79340)

Hi! As mentioned in the PR, on the gfortran.dg/forall_7.f90 testcase we leak memory starting with r239542. vect_get_slp_defs allocates a vector of vectors, elements corresponding to NULL in slp_ops are .create (0) vectors that don't need freeing, but the rest is safe_spliced into other vectors.

[PATCH, rs6000] gcc 5 back port of vec_packs and vec_vgbbd builtin table entry fixes

GCC Maintainers: The GCC 6 branch for the back port of the following two mainline commits was approved and committed to GCC 6. The following patch is the back port for the two commits for the GCC 5 branch. The only difference relative to the GCC 6 patch is the line numbers. mainline commits.

Re: [PATCH/AARCH64] Enable software prefetching (-fprefetch-loop-arrays) for ThunderX 88xxx

On Fri, Feb 3, 2017 at 4:00 AM, Maxim Kuvyrkov wrote: > Hi Andrew, > > I took the liberty of rebasing your patch on top of my patchset. Does it > look correct? Yes this looks correct. Thanks, Andrew > > I think I addressed all the comments you had about my review

Re: New Port for RISC-V v2

On Fri, 3 Feb 2017, Palmer Dabbelt wrote: > How do these look? Fine for readings.html. backends.html, not my cup of tea. ;-) Gerald

Re: [PATCH] diagnostics: fix end-points of ranges within macros (PR c++/79300)

On 02/03/2017 01:52 PM, David Malcolm wrote: IIRC you had another issue that was borderline, but which we did want to move forward on gcc-7. The reported testcase was a problem with a new warning, but the underlying issue could (in theory) be tripped for existing warnings. RIght? I think

[PATCH] PR target/66144, PowerPC improve vector compare

This patch improves the code generation for: vector char compare_vc (vector char a, vector char b) { return a == b; } Previously it generated: vcmpequb 2,2,3 vspltisw 1,-1 vspltisw 0,0 xxsel 34,32,33,34 and now it

[PATCH/AARCH64] Fix ThunderX core definition

Hi, It turns out due to a hardware issue, LSE support is turned off. This patch updates the thunderx cores to disable LSE and 8.1 where as needed. OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. Thanks, Andrew Pinski ChangeLog: * config/aarch64/aarch64-cores.def

Re: [PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

On Fri, Feb 03, 2017 at 09:11:38PM +0100, Jakub Jelinek wrote: > On Fri, Feb 03, 2017 at 03:05:58PM -0500, Michael Meissner wrote: > > > > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03 > > > > 02:37:44.147938375 +0100 > > > > +++ gcc/testsuite/gcc.target/powerpc/pr79354.c

Re: [PATCH] diagnostics: fix end-points of ranges within macros (PR c++/79300)

On Fri, 2017-02-03 at 13:28 -0700, Jeff Law wrote: > On 02/02/2017 01:53 PM, David Malcolm wrote: > > PR c++/79300 identifies an issue in which diagnostics_show_locus > > prints the wrong end-point for a range within a macro: > > > >assert ((p + val_size) - buf == encoded_len); > >

Re: New Port for RISC-V v2

On Thu, 02 Feb 2017 17:08:06 PST (-0800), Palmer Dabbelt wrote: > On Thu, 02 Feb 2017 09:58:32 PST (-0800), jos...@codesourcery.com wrote: >> On Thu, 2 Feb 2017, Palmer Dabbelt wrote: >> >>> Additionally, here's a diff against wwwdocs. This is really just to check >>> this >>> is all I'm

Re: [PATCH] diagnostics: fix end-points of ranges within macros (PR c++/79300)

On 02/02/2017 01:53 PM, David Malcolm wrote: PR c++/79300 identifies an issue in which diagnostics_show_locus prints the wrong end-point for a range within a macro: assert ((p + val_size) - buf == encoded_len); ~^~~~ as opposed to: assert ((p + val_size) -

Re: [PATCH] Fix improper combiner optimization of mixed mode vector/scalar expressions (PR 79365)

On 2/3/2017 3:03 PM, Walter Lee wrote: Hi, In looking at PR 79365 I found that the problem is actually in the combiner. The combiner sometimes applies scalar optimizations to vector context where they are invalid. i.e. (a > b) >> 1 can optimize to 0 if ">" is a scalar op but not if it is a

[PATCH] sched: Do not move expensive insns speculatively (PR68664)

Scheduling should never move very expensive instructions to places they are executed more frequently. This patch fixes that, reducing the execution time of c-ray by over 40% (I tested on a BE Power7 system). This introduces a new target hook sched.can_speculate_insn which returns whether the

Re: [PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

On Fri, Feb 03, 2017 at 03:05:58PM -0500, Michael Meissner wrote: > > > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03 > > > 02:37:44.147938375 +0100 > > > +++ gcc/testsuite/gcc.target/powerpc/pr79354.c2017-02-03 > > > 02:38:34.838303987 +0100 > > > @@ -0,0 +1,23 @@ > > > +/*

Re: [PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

On Fri, Feb 03, 2017 at 09:59:45AM -0600, Segher Boessenkool wrote: > Hi Jakub, > > On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote: > > As mentioned in the PR, for the following testcase we emit a power9 > > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction >

[PATCH] Fix improper combiner optimization of mixed mode vector/scalar expressions (PR 79365)

Hi, In looking at PR 79365 I found that the problem is actually in the combiner. The combiner sometimes applies scalar optimizations to vector context where they are invalid. i.e. (a > b) >> 1 can optimize to 0 if ">" is a scalar op but not if it is a vector op. The reason this shows up on

C++ PATCH for c++/79294 (ICE with invalid pointer-to-function template argument)

In this testcase, if we saw a value-dependent expression we were leaving its type unchanged, leading to an abort at the end of the function. Instead, we should complain about an argument with the wrong type. Tested x86_64-pc-linux-gnu, applying to trunk. commit

Re: [PATCH][C++] Improve memory use for PR12245

On Thu, Feb 2, 2017 at 4:21 AM, Richard Biener wrote: > On Wed, 1 Feb 2017, Richard Biener wrote: > >> On Wed, 1 Feb 2017, Jakub Jelinek wrote: >> >> > On Wed, Feb 01, 2017 at 02:14:20PM +0100, Richard Biener wrote: >> > > >> > > Looks like we cache the answer to

Re: [PATCH] PR66145 use new ABI for std::ios::failure exceptions

On 16/01/17 15:57 +, Jonathan Wakely wrote: This changes the version of std::ios_base::failure thrown by libstdc++.so to be the new __cxx11 ABI one, matching the default for headers that are trying to catch the exception. There's no simple way to do this as an easy transition, but hopefully

[PATCH, committed] TILEPro/TILE-Gx: add blockage to avoid bad scheduler + dwarf interaction (PR target/78862)

This patch fixes PR target/78862. Add blockage to prevent the scheduler from reordering a LR save with a subsequent instruction that changes the CFA register. This trips up the dwarf generating logic. Bootstrapped and tested on TILEPro/TILE-Gx hardware, also backported to GCC 6. *

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/03/2017 12:02 PM, Jeff Law wrote: On 02/02/2017 05:31 PM, Martin Sebor wrote: - T (2, "%#hho",a); /* { dg-warning "nul past the end" } */ - T (2, "%#hhx",a); /* { dg-warning ".%#hhx. directive writing between 3 and . bytes into a region of size 2" } */ + T (2,

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/02/2017 05:49 PM, Martin Sebor wrote: That is unrelated to the patch, both in the current trunk, with your patch as well as with my patch there is just res.range.likely = res.knownrange ? res.range.max : res.range.min; res.range.unlikely = res.range.max; for these cases. Do you want

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/02/2017 05:31 PM, Martin Sebor wrote: - T (2, "%#hho",a); /* { dg-warning "nul past the end" } */ - T (2, "%#hhx",a); /* { dg-warning ".%#hhx. directive writing between 3 and . bytes into a region of size 2" } */ + T (2, "%#hho",a); + T (2, "%#hhx",

[PATCH] PR libstdc++/60936 reduce coupling between objects in libstdc++.a

Move explicit instantiation definitions for string I/O functions into their own files so that iostream and locale definitions are not needed for uses of strings without I/O. Move functions for throwing C++11 exceptions into the individual files defining the exception types, so that using any of

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On Fri, Feb 03, 2017 at 11:43:53AM -0700, Jeff Law wrote: > > + if (TREE_CODE (argtype) == POINTER_TYPE) > > { > > - if (POINTER_TYPE_P (argtype)) > > - argmax = build_all_ones_cst (argtype); > > - else if (TYPE_UNSIGNED (argtype)) > > - argmax = TYPE_MAX_VALUE

[PATCH, i386]: Use pextr for TARGET_SSE4_1 when creating STV scalar copy

Hello! This patch fixes asymmetry for TARGET_SSE4_1, where pinsr was used to create vector copy, but not pextr when creating scalar copy with -mstv. 2017-02-03 Uros Bizjak * config/i386/i386.c (dimode_scalar_chain::convert_reg): Use pextrd for TARGET_SSE4_1 when

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/02/2017 03:15 PM, Jakub Jelinek wrote: Plus there are certain notes removed: -builtin-sprintf-warn-1.c:1311:3: note: using the range [1, -2147483648] for directive argument T (0, "%d", a); /* { dg-warning "into a region" } */ without replacement, here a has [-2147483648,

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/02/2017 07:12 AM, Jakub Jelinek wrote: On Thu, Feb 02, 2017 at 10:52:18AM +0100, Jakub Jelinek wrote: That said, as I've said in the PR and earlier in December on gcc-patches, the way format_integer is structured is not really maintainable, has very different code paths for arguments with

Re: [PATCH, rs6000] gcc 6 back port of vec_packs and vec_vgbbd builtin table entry fixes

On Fri, Feb 03, 2017 at 09:57:31AM -0800, Carl E. Love wrote: > I have squashed the following two patches from mainline > > commit r244943 Remove bogus entries for the P8V_BUILTIN_VEC_VGBBD > built-ins > commit r244904 Fix order of entries for ALTIVEC_BUILTIN_VEC_PACKS >

[PATCH, rs6000] gcc 6 back port of vec_packs and vec_vgbbd builtin table entry fixes

GCC Maintainers: I have squashed the following two patches from mainline commit r244943 Remove bogus entries for the P8V_BUILTIN_VEC_VGBBD built-ins commit r244904 Fix order of entries for ALTIVEC_BUILTIN_VEC_PACKS and P8V_BUILTIN_VEC_VGBBD. and back ported

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/03/2017 09:39 AM, Jakub Jelinek wrote: On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote: I'm not opposed to the changes, certainly not to cleaning things up, but I don't think now is the time to be making these tweaks. Jakub's patch is fine with me without those tweaks, and

Re: [PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

On Fri, Feb 03, 2017 at 09:59:45AM -0600, Segher Boessenkool wrote: > Hi Jakub, > > On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote: > > As mentioned in the PR, for the following testcase we emit a power9 > > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction >

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On Fri, Feb 03, 2017 at 10:02:48AM -0700, Martin Sebor wrote: > On 02/03/2017 09:39 AM, Jakub Jelinek wrote: > > On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote: > > > I'm not opposed to the changes, certainly not to cleaning things up, > > > but I don't think now is the time to be

[PATCH][AArch64] Accept more addressing modes for PRFM

Hi all, While evaluating Maxim's SW prefetch patches [1] I noticed that the aarch64 prefetch pattern is overly restrictive in its address operand. It only accepts simple register addressing modes. In fact, the PRFM instruction accepts almost all modes that a normal 64-bit LDR supports. The

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/03/2017 09:39 AM, Jakub Jelinek wrote: On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote: I'm not opposed to the changes, certainly not to cleaning things up, but I don't think now is the time to be making these tweaks. Jakub's patch is fine with me without those tweaks, and

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote: > I'm not opposed to the changes, certainly not to cleaning things up, > but I don't think now is the time to be making these tweaks. Jakub's > patch is fine with me without those tweaks, and with the correction What do you mean by my

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Fri, Feb 03, 2017 at 04:19:58PM +, Ramana Radhakrishnan wrote: > > > Would it be acceptable for those users to have loads that perform like > > > CAS loops, especially under contention? Or are these users more > > > concerned about aarch64 not offering a true atomic 16-byte load? > > > >

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On 03/02/17 15:13, Jakub Jelinek wrote: On Fri, Feb 03, 2017 at 04:07:22PM +0100, Torvald Riegel wrote: On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote: __atomic_load on ARM appears to be ok as well except for __atomic_load_di which should really be the ldrexd / strexd loop but

Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

On 02/03/2017 12:35 AM, Jeff Law wrote: On 02/02/2017 09:58 AM, Martin Sebor wrote: Otherwise all the tests succeeded, though looking e.g. at the diff between builtin-sprintf-warn-1.c diagnostics with your patch and with the patch below instead, there are also differences like:

Re: [PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

Hi Jakub, On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote: > As mentioned in the PR, for the following testcase we emit a power9 > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction > uses wb constraint for the stxssp insn source rather than wu, which it > only

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Fri, Feb 03, 2017 at 04:07:22PM +0100, Torvald Riegel wrote: > On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote: > > __atomic_load on ARM appears to be ok as well > > > > except for > > > > __atomic_load_di which should really be the ldrexd / strexd loop but we > > could

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote: > __atomic_load on ARM appears to be ok as well > > except for > > __atomic_load_di which should really be the ldrexd / strexd loop but we > could ameliorate that similar to your option 3b. This uses just ldrexd now, and thus is

[wwwdocs] Uncomment link to gcc-7/porting_to.html

We now have a porting_to.html for gcc 7, so this patch uncomments the link to it on gcc 7's changes page. Validates. I took the liberty of committing this, under the "obvious" rule. Index: htdocs/gcc-7/changes.html === RCS file:

Re: [wwwdocs] Add various new warnings for GCC 7

On Thu, Feb 02, 2017 at 10:24:34PM +0100, Gerald Pfeifer wrote: > Hi Marek, > > a couple of comments (and minor changes) below. Once you have made > those, this is okay to commit. Quite some stuff going into GCC 7! > > On Fri, 27 Jan 2017, Marek Polacek wrote: > > Index: changes.html > >

Re: [wwwdocs] Mention GIMPLE and RTL frontends in changes.html

On Fri, 2017-02-03 at 08:09 +0100, Gerald Pfeifer wrote: > On Thu, 2 Feb 2017, David Malcolm wrote: > > This patch to the website moves the section about the selftest > > suite to > > the bottom of "Other significant improvements" section, and > > rewrites it > > to also cover the GIMPLE and RTL

Re: [PATCH] Fix __atomic to not implement atomic loads with CAS.

On 02/02/17 15:21, Torvald Riegel wrote: On Thu, 2017-02-02 at 14:48 +, Ramana Radhakrishnan wrote: On 30/01/17 18:54, Torvald Riegel wrote: This patch fixes the __atomic builtins to not implement supposedly lock-free atomic loads based on just a compare-and-swap operation. If there is no

Re: [PATCH] Make multiple_target.c aware of LTO (PR lto/66295)

On 02/02/2017 02:18 PM, Martin Liška wrote: > Ok, I spent more time with understanding how that pass works and I believe it > can be > significantly simplified. I guess target_clones are very close to 'target' > attribute > that is handled by C++ FE. It creates cgraph_function_version_info and

Re: [PATCH] Make multiple_target.c aware of LTO (PR lto/66295)

On 02/02/2017 02:18 PM, Martin Liška wrote: > Ok, I spent more time with understanding how that pass works and I believe it > can be > significantly simplified. I guess target_clones are very close to 'target' > attribute > that is handled by C++ FE. It creates cgraph_function_version_info and

Re: [PATCH] IPA: enhance dump output

On 02/02/2017 03:54 PM, Jan Hubicka wrote: >> 2017-01-24 Martin Liska >> >> * cgraph.c (cgraph_node::dump): Dump function version info. >> * symtab.c (symtab_node::dump_base): Add missing new line. >> --- >> gcc/cgraph.c | 10 ++ >> gcc/symtab.c | 1 + >> 2

Re: [PATCH/AARCH64] Enable software prefetching (-fprefetch-loop-arrays) for ThunderX 88xxx

Hi Andrew, I took the liberty of rebasing your patch on top of my patchset. Does it look correct? I think I addressed all the comments you had about my review and posted updated patches. -- Maxim Kuvyrkov www.linaro.org > On Jan 30, 2017, at 7:25 PM, Andrew Pinski

Re: [PATCH 5/6][AArch64] Enable -fprefetch-loop-arrays at -O3 for cores that benefit from prefetching.

> On Jan 30, 2017, at 5:50 PM, Maxim Kuvyrkov wrote: > >> On Jan 30, 2017, at 3:23 PM, Kyrill Tkachov >> wrote: >> >> Hi Maxim, >> >> On 30/01/17 12:06, Maxim Kuvyrkov wrote: >>> This patch enables prefetching at -O3 for aarch64 cores

Re: [PATCH 4/6] Port prefetch configuration from aarch32 to aarch64

> On Jan 30, 2017, at 7:35 PM, Andrew Pinski wrote: > > On Mon, Jan 30, 2017 at 3:48 AM, Maxim Kuvyrkov > wrote: >> This patch port prefetch configuration from aarch32 backend to aarch64. >> There is no code-generation change from this patch. >>

Re: [PATCH][PR sanitizer/78663] Fix 'dyld: Symbol not found: _memmem' linkage error on Darwin 10.6.

On Fri, Feb 03, 2017 at 02:46:39PM +0300, Maxim Ostapenko wrote: > Hi, > > this patch fixes 'dyld: Symbol not found: _memmem' linkage error on Darwin > 10.6. > Just cherry-pick r293992 from upstream, OK to apply? > > -Maxim > libsanitizer/ChangeLog: > > 2017-02-03 Maxim Ostapenko

[PATCH][PR sanitizer/78663] Fix 'dyld: Symbol not found: _memmem' linkage error on Darwin 10.6.

Hi, this patch fixes 'dyld: Symbol not found: _memmem' linkage error on Darwin 10.6. Just cherry-pick r293992 from upstream, OK to apply? -Maxim libsanitizer/ChangeLog: 2017-02-03 Maxim Ostapenko PR sanitizer/78663 * sanitizer_common/sanitizer_mac.cc:

Re: [PATCH][DOC][OBVIOUS] Document default value for use-after-scope-direct-emission-threshold

On 02/03/2017 10:45 AM, Gerald Pfeifer wrote: > On Fri, 3 Feb 2017, Martin Liška wrote: >> Installed as obvious as r245147. > > Yes, but... Hi. Thanks for that, stupid typos. > > I think you wanted to say "is 256", not "in 256" and make this a > full sentence? Looking at the entire entry I

Re: [PATCH v2,rs6000] PR78056: Finish fixing build failure on Power7

On Dez 16 2016, Kelvin Nilsen wrote: > Index: gcc/testsuite/gcc.target/powerpc/pr78056-8.c > === > --- gcc/testsuite/gcc.target/powerpc/pr78056-8.c (revision 0) > +++

Re: [PATCH] [AArch64] Implement popcount pattern

On 03/02/17 06:57, Hurugalawadi, Naveen wrote: Hi Andrew, Thanks for clearing the confusion. I don't understand this comment and how it relates to your updated patch foo, foo1 and foo2 generates calls to "popcountdi2" which should have been "popcountsi2" for foo1. When Kyrill commented on

Re: [PATCH][DOC][OBVIOUS] Document default value for use-after-scope-direct-emission-threshold

On Fri, 3 Feb 2017, Martin Liška wrote: > Installed as obvious as r245147. Yes, but... I think you wanted to say "is 256", not "in 256" and make this a full sentence? Looking at the entire entry I noticed a few other issues ("smaller of equal" instead of "smaller or equal", missing articles,

Re: [PATCH] assume arrays at end of structs are unbounded (PR 79352)

Hi! Some formatting nits: On Thu, Feb 02, 2017 at 10:10:32PM -0700, Martin Sebor wrote: > else if (gimple_assign_rhs_code (def_stmt) == COND_EXPR) > { > tree op2 = gimple_assign_rhs2 (def_stmt); > tree op3 = gimple_assign_rhs3 (def_stmt); > - return

Re: [wwwdocs] Added /gcc-7/porting_to.html

On 3 February 2017 at 07:56, Gerald Pfeifer wrote: > On Mon, 30 Jan 2017, Jonathan Wakely wrote: >> >> This adds the porting to guide for GCC 7. So far it only has details >> of C++ changes, mostly in the std::lib. > > > Thanks for doing that, Jonathan! > > One minor observation: This has

Re: [PATCH] Fix PR79278, amend ADJUST_FIELD_ALIGN interface

> On 2 Feb 2017, at 08:08, Richard Biener wrote: > > On Wed, 1 Feb 2017, Segher Boessenkool wrote: > >> On Wed, Feb 01, 2017 at 03:53:09PM -0600, Segher Boessenkool wrote: >>> On Wed, Feb 01, 2017 at 11:59:10AM +0100, Richard Biener wrote: Wasn't successful in making a

[PATCH][DOC][OBVIOUS] Document default value for use-after-scope-direct-emission-threshold

Hello. Installed as obvious as r245147. Martin >From 705314a0d896e5434dcb30b6e5790fc5dab132b4 Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 3 Feb 2017 10:07:05 +0100 Subject: [PATCH] Document default value for use-after-scope-direct-emission-threshold gcc/ChangeLog:

[PATCH] Fix powerpc movsi_from_sf define_insn_and_split constraints (PR target/79354)

Hi! As mentioned in the PR, for the following testcase we emit a power9 instruction even with -mcpu=power8. Similar movsf_hardfloat instruction uses wb constraint for the stxssp insn source rather than wu, which it only uses for stxsspx (power7?). Bootstrapped/regtested on powerpc64{,le}-linux,

Re: PR79286, ira combine_and_move_insns in loops

On 02/02/2017 02:31 AM, Alan Modra wrote: Revised patch that cures the lra related -m32 -Os regression too. The code that I'm patching here is changing a REG_EQUAL note to REG_EQUIV, ie. asserting that the value of the reg is always the value set by the current instruction. Which is not always

Re: [patch,wwwdocs] Add v7 AVR release notes.

On Fri, 7 Oct 2016, Georg-Johann Lay wrote: Mentioning some AVR target specific improvements. Below some small editorial changes that I just applied on top of this. Gerald Index: gcc-7/changes.html === RCS file:

Re: [wwwdocs, coding conventions] Mention OVERRIDE/FINAL

On Fri, 14 Oct 2016, David Malcolm wrote: > On Fri, 2016-10-14 at 16:27 +0100, Pedro Alves wrote: >> FYI, I pushed these in now. I also bootstrapped with the >> jit included in the selected languages, and hacked the >> jit code a bit to trigger the problems OVERRIDE intends to >> catch, just to

Re: [PATCH] assume arrays at end of structs are unbounded (PR 79352)

On 02/02/2017 10:10 PM, Martin Sebor wrote: Bug 79352 points out that the gimple-ssa-printf pass doesn't allow for an array at the end of a struct to be treated as a poor man's flexible array member and hold a string that's longer than the upper bound of the array. Rather, the pass assumes that

Re: [wwwdocs] Consistently use "testsuite"

On Fri, 3 Feb 2017, Gerald Pfeifer wrote: > Of course, an innocent grep after providing this input in a review > of a patch by David revealed that we have a number more cases where > we used "test suite" instead of "testsuite". And now a recursive grep. Applied. Gerald Index: