Re: [RFC][IPA-VRP] Early VRP Implementation

On September 14, 2016 11:36:16 PM GMT+02:00, Jan Hubicka wrote: >> + /* Visit PHI stmts and discover any new VRs possible. */ >> + gimple_stmt_iterator gsi; >> + for (gphi_iterator gpi = gsi_start_phis (bb); >> + !gsi_end_p (gpi); gsi_next ()) >> +{ >> + gphi

Re: [PATCH 1/8] change a few rtx_insn * to rtx_jump_insn *

Trevor Saunders wrote: >> This hunk results several new failures for tree-profile tests on SH. >> If the line "if (JUMP_P (cur_insn))" is restored, those failures >> go away. > > That's interesting because dyn_cast should include that check. What is > the error? Here is

Re: [PATCH 1/8] change a few rtx_insn * to rtx_jump_insn *

On Thu, Sep 15, 2016 at 01:04:04PM +0900, Kaz Kojima wrote: > tbsaunde+...@tbsaunde.org wrote: > > @@ -2201,8 +2201,7 @@ fix_crossing_unconditional_branches (void) > > { > > if (!BARRIER_P (cur_insn)) > > BLOCK_FOR_INSN (cur_insn) = cur_bb; > > -

Re: [PATCH 1/8] change a few rtx_insn * to rtx_jump_insn *

tbsaunde+...@tbsaunde.org wrote: > @@ -2201,8 +2201,7 @@ fix_crossing_unconditional_branches (void) > { > if (!BARRIER_P (cur_insn)) > BLOCK_FOR_INSN (cur_insn) = cur_bb; > - if (JUMP_P (cur_insn)) > - jump_insn =

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On 14 September 2016 at 18:54, Richard Biener wrote: > On Fri, Sep 9, 2016 at 12:38 PM, Prasad Ghangal > wrote: >> On 26 August 2016 at 14:28, Richard Biener >> wrote: >>> On Fri, Aug 26, 2016 at 5:08 AM, Prasad

Re: [PATCH] PR fortran/77420 -- take two

On 09/14/2016 02:49 PM, Steve Kargl wrote: The attached patch appears to fix PR fortran/77420 without causing regressions. The problem raised by Andrew Benson at https://gcc.gnu.org/ml/fortran/2016-09/msg00039.html contained in pr77420_3.f90 and pr77420_4.f90. The original testcase from the PR

Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled

> I think the approach is reasonable though it might still have > interesting effects on > optimization for very small growth. So for further experimenting it > would be nice Test it on SPEC CPU with FDO enabled? > to have a separate PARAM_EARLY_FDO_INLINING_INSNS or maybe simply > adjust the

Re: [PING] set libfunc entry for sdivmod_optab to NULL in optabs.def

Richard Sandiford writes: > Prathamesh Kulkarni writes: >> Hi, >> I would like to ping the following patch: >> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html >> >> While implementing divmod transform: >>

Re: [PING] set libfunc entry for sdivmod_optab to NULL in optabs.def

Prathamesh Kulkarni writes: > Hi, > I would like to ping the following patch: > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html > > While implementing divmod transform: > https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html > > I ran into an issue

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Wed, Sep 14, 2016 at 01:35:57PM -0600, Jeff Law wrote: > On 09/14/2016 01:03 PM, Segher Boessenkool wrote: > > > >(There is no return insn at those exits; these are exits *without* > >successor block, not the exit block). > Hmm, I thought these were return blocks, but you're saying they're >

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Wed, Sep 14, 2016 at 01:33:04PM -0600, Jeff Law wrote: > On 09/14/2016 01:03 PM, Segher Boessenkool wrote: > >>If you think about it, conceptually we want the return insn to make the > >>callee saved registers "used" so that DCE, regrename and friends don't > >>muck with them. The fact that we

Re: [PATCH 3/9] selftest.h: add temp_override fixture

On Thu, Sep 08, 2016 at 08:30:47PM -0400, David Malcolm wrote: > We have a lot of global state in our code. Ideally we'd reduce the > amount of such global state, but a prerequisite for sane refactoring > is having automated testing in place to ensure that the refactoring > doesn't break

[PATCH] PR fortran/77420 -- take two

The attached patch appears to fix PR fortran/77420 without causing regressions. The problem raised by Andrew Benson at https://gcc.gnu.org/ml/fortran/2016-09/msg00039.html contained in pr77420_3.f90 and pr77420_4.f90. The original testcase from the PR is in pr77420_1.f90 and a variation on that

Patch ping

Hi! I'd like to ping a couple of patches: C++ === http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html - PR77375 - wrong-code with mutable members in base classes http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html - PR77338 - fix constexpr ICE on PARM_DECL with incomplete type

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

On Sep 14, 2016, at 1:19 PM, Moritz Klammler wrote: > > Joseph Myers writes: > >> On Wed, 14 Sep 2016, Moritz Klammler wrote: >> >>> Ok, I didn't know about the workflow. Do you think I should dike the >>> `--strip-sums` option out again then? >>

Re: [RFC][IPA-VRP] Early VRP Implementation

> + /* Visit PHI stmts and discover any new VRs possible. */ > + gimple_stmt_iterator gsi; > + for (gphi_iterator gpi = gsi_start_phis (bb); > + !gsi_end_p (gpi); gsi_next ()) > +{ > + gphi *phi = gpi.phi (); > + tree lhs = PHI_RESULT (phi); > + value_range vr_result =

libgo patch committed: Fix typo in libgo/configure.ac

This patch fixes a typo in libgo/configure.ac (PCQUANTUm -> PCQUANTUM). Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision 240083) +++

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

Joseph Myers writes: > On Wed, 14 Sep 2016, Moritz Klammler wrote: > >> Ok, I didn't know about the workflow. Do you think I should dike the >> `--strip-sums` option out again then? > > I don't see any use for such an option. Anyone changing the versions > should

Re: debug container mutex association

On 14/09/2016 11:00, Jonathan Wakely wrote: On 13/09/16 22:37 +0200, François Dumont wrote: Hi When I proposed to change std::hash for pointers my plan was to use this approach for the debug containers. So here is the patch leveraging on this technique to avoid going through _Hash_impl to

[PATCH,committed] Infer architecture from ABI for mips-img* and mips-mti*

This patch allows the -mabi=n32 and -mabi=64 options to automatically infer the of a 64-bit architecture in the mips-mti-* and mips-img-* triplets. The default 64-bit architecture is mips64r2 for MTI and mips64r6 for IMG. Thanks, Matthew gcc/ * config.gcc (mips*-mti-elf*,

Re: [PATCHv3] Add a warning for suspicious use of conditional expressions in boolean context

... resent, because message apparently bounced. On 09/14/16 21:22, Bernd Edlinger wrote: > On 09/14/16 20:11, Jason Merrill wrote: >>> >>> Yes. The reasoning I initially had was that it is completely >>> pointless to have something of the form "if (x ? 1 : 2)" or >>> "if (x ? 0 : 0)" because the

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 01:03 PM, Segher Boessenkool wrote: (There is no return insn at those exits; these are exits *without* successor block, not the exit block). Hmm, I thought these were return blocks, but you're saying they're no-return blocks? I missed that. In that case, aren't the restores

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 01:03 PM, Segher Boessenkool wrote: If you think about it, conceptually we want the return insn to make the callee saved registers "used" so that DCE, regrename and friends don't muck with them. The fact that we don't is as much never having to care all that much until recently.

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 01:10 PM, Segher Boessenkool wrote: On Wed, Sep 14, 2016 at 11:52:02AM -0600, Jeff Law wrote: Yea, it'll certainly do that and I can imagine a design which would have that property. And there's other designs which benefit from spreading across the register file as much as

[PATCH 5/8] make prev_real_insn take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-13 Trevor Saunders * emit-rtl.c (prev_real_insn): Change argument type to rtx_insn *. * rtl.h: Adjust prototype. * config/sh/sh.md: Adjust. * dwarf2out.c

[PATCH 7/8] make next/prev active_insn and active_insn_p take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-14 Trevor Saunders * emit-rtl.c (next_active_insn): Change argument type to rtx_insn *. (prev_active_insn): Likewise. (active_insn_p): Likewise. *

[PATCH 8/8] make next_cc0_user take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-14 Trevor Saunders * emit-rtl.c (next_cc0_user): Make argument type rtx_insn *. * rtl.h: Adjust prototype. --- gcc/emit-rtl.c | 4 +--- gcc/rtl.h | 2 +- 2 files changed,

[PATCH 6/8] make next/prev nonnote_nondebug_insn take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-14 Trevor Saunders * config/cris/cris.c (cris_asm_output_case_end): Change argument type to rtx_insn *. * emit-rtl.c (next_nonnote_nondebug_insn): Likewise.

[PATCH 3/8] make next/prev _nonnote_insn take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-13 Trevor Saunders * emit-rtl.c (next_nonnote_insn): Change argument type to rtx_insn *. (prev_nonnote_insn): Likewise. * jump.c

[PATCH 4/8] make next/prev nondebug_insn take rtx_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-13 Trevor Saunders * emit-rtl.c (next_nondebug_insn): Change argument type to rtx_insn *. (prev_nondebug_insn): Likewise. * loop-doloop.c

[PATCH 2/8] use rtx_insn * more

From: Trevor Saunders gcc/ChangeLog: 2016-09-06 Trevor Saunders * config/arc/arc-protos.h (arc_label_align): Change type of variables from rtx to rtx_insn *. * config/arc/arc.c (arc_label_align): Likewise.

[PATCH 1/8] change a few rtx_insn * to rtx_jump_insn *

From: Trevor Saunders gcc/ChangeLog: 2016-09-06 Trevor Saunders * bb-reorder.c (fix_crossing_unconditional_branches): Make type of jump_insn rtx_jump_insn *. * reorg.c (steal_delay_list_from_target): Make type of

[PATCH 0/8] make next_*_insn take rtx_insn * arguments

From: Trevor Saunders Hi, Basically $subject. First change variable's type to rtx_insn * where possible. Then change the functions and fixup callers where it is still necessary to cast. patches bootstrapped and regtested individually on x86_64-linux-gnu, and the

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Wed, Sep 14, 2016 at 11:52:02AM -0600, Jeff Law wrote: > Yea, it'll certainly do that and I can imagine a design which would have > that property. And there's other designs which benefit from spreading > across the register file as much as possible. > > Which argues there needs to be a way

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Wed, Sep 14, 2016 at 12:11:50PM -0600, Jeff Law wrote: > On 09/14/2016 07:04 AM, Segher Boessenkool wrote: > >>I'd > >>probably start by fixing the dataflow issues and see if that fixes the > >>regrename thing as a side effect. > > > >Have you seen

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 08:01 AM, Bernd Schmidt wrote: On 09/14/2016 03:55 PM, Segher Boessenkool wrote: On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: The data that was posted showed a code size decrease on a number of targets. I'm really not sure where this irrational hate for

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On Wed, Sep 14, 2016 at 1:37 PM, Bernd Edlinger wrote: > On 09/14/16 18:37, Jason Merrill wrote: >> On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger >> wrote: >>> The other false positive was in dwarf2out, where we have this: >>> >>>

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 07:04 AM, Segher Boessenkool wrote: I'd probably start by fixing the dataflow issues and see if that fixes the regrename thing as a side effect. Have you seen https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00091.html ? I missed it. My interpretation The uses at each

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

On Wed, 14 Sep 2016, Moritz Klammler wrote: > Ok, I didn't know about the workflow. Do you think I should dike the > `--strip-sums` option out again then? I don't see any use for such an option. Anyone changing the versions should always have a copy of the new tarball (obtained securely if

Re: [C++ PATCH] Fix ICE in C++ lookup_name_fuzzy (PR c++/77549, take 2)

OK, thanks. On Wed, Sep 14, 2016 at 3:43 AM, Jakub Jelinek wrote: > On Tue, Sep 13, 2016 at 11:46:52PM -0400, Jason Merrill wrote: >> On Tue, Sep 13, 2016 at 3:26 PM, Jakub Jelinek wrote: >> >for (tree t = lvl->names; t; t = TREE_CHAIN (t)) >> > { >>

Re: [PATCH] Improve string::clear() performance

On Wed, Sep 14, 2016 at 10:28 AM, Jonathan Wakely wrote: > On 14/09/16 09:09 -0700, Cong Wang wrote: >> >> On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely >> wrote: >>> >>> If I understand the purpose of the change correctly, it's similar to >>>

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On 09/14/16 19:40, Steve Kargl wrote: > On Wed, Sep 14, 2016 at 04:10:46PM +, Bernd Edlinger wrote: >> >> fortran: >> 2016-09-14 Bernd Edlinger >> >> PR c++/77434 >> * simplify.c (gfc_simplify_repeat): Fix a warning. >> >> Index: gcc/fortran/simplify.c

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 07:55 AM, Segher Boessenkool wrote: On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: On 09/14/2016 03:04 PM, Segher Boessenkool wrote: Then rs6000 (and many other ports probably) will just turn it off again. It is actively harmful. The data that was posted showed

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On Wed, Sep 14, 2016 at 04:10:46PM +, Bernd Edlinger wrote: > > fortran: > 2016-09-14 Bernd Edlinger > > PR c++/77434 > * simplify.c (gfc_simplify_repeat): Fix a warning. > > Index: gcc/fortran/simplify.c >

Re: C++ PATCH to forbid use of bool with the ++ operator

OK, thanks. On Wed, Sep 14, 2016 at 11:28 AM, Marek Polacek wrote: > On Tue, Sep 13, 2016 at 11:37:20PM -0400, Jason Merrill wrote: >> On Tue, Sep 13, 2016 at 3:55 PM, Martin Sebor wrote: >> > Having said all that, since this is C++ the message could and >>

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On 09/14/16 18:37, Jason Merrill wrote: > On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger > wrote: >> The other false positive was in dwarf2out, where we have this: >> >> ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integer >> constants in boolean context

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

Joseph Myers writes: > On Wed, 14 Sep 2016, Moritz Klammler wrote: > >> be cleaner to only include those checksums that are actually needed. On >> the other hand, it means an increased maintenance burden each time the >> version of the dependency is changed. In order

Re: [PATCH] Improve string::clear() performance

On 14/09/16 09:09 -0700, Cong Wang wrote: On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely wrote: On 13/09/16 11:02 -0700, Cong Wang wrote: In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls _M_mutate(), which could allocate memory as we do COW. This hurts

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

On Wed, 14 Sep 2016, Moritz Klammler wrote: > be cleaner to only include those checksums that are actually needed. On > the other hand, it means an increased maintenance burden each time the > version of the dependency is changed. In order to mitigate this and I really don't see it as an

[PATCH] Fix incorrect setting of edge probability in loop unroller

The following patch corrects a problem with setting the probability on the pred edge instead of the newly created fallthru succ edge. Bootstrap/regtest on powerpc64le with no new regressions. Committed as obvious. -Pat 2016-09-14 Pat Haugen * loop-unroll.c

Re: [PATCH] Optimize strchr (s, 0) to strlen

On 14/09/16 14:45, Jakub Jelinek wrote: > I think for the middle-end, using strchr (a, 0) as canonical instead of a + > strlen (a) > is better, and at expansion time we can decide what to use (a + strlen (a) > if you'd expand strlen inline, rather than as a function call, or > __rawmemchr (which

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

Attached is an updated patch that does away with the "overlapping" warning and instead issues the same warnings as the C front end (though with more context). In struct flexmems_t I've retained the NEXT array even though only the first element is used to diagnose problems. The second element is

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

Richard Biener writes: > On Tue, Sep 13, 2016 at 6:01 PM, Joseph Myers wrote: >> On Tue, 13 Sep 2016, Moritz Klammler wrote: >> >>> I have made an actual diff now, containing also the checksum files. >>> I >> >> I don't think checksums of

Re: [PATCH] Tree-level fix for PR 69526

[ Another patch I'd started working through, but hadn't completed... ] On 09/14/2016 07:05 AM, Richard Biener wrote: On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote: if !inner_ovf (just set that to false if !check_inner_ovf to simplify checks please). you know it's

Re: [PATCH GCC 6/9]Simplify control flow graph for vectorized loop

On 09/14/2016 07:21 AM, Richard Biener wrote: On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote: Hi, This is the main patch improving control flow graph for vectorized loop. It generally rewrites loop peeling stuff in vectorizer. As described in patch, for a typical loop

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger wrote: > The other false positive was in dwarf2out, where we have this: > > ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integer > constants in boolean context [-Werror=int-in-bool-context] >if

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

Hi! On Tue, 13 Sep 2016 16:27:39 +0200, Bernd Schmidt wrote: > On 09/13/2016 04:24 PM, Jason Merrill wrote: > > > But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead > > of on x86; is this OK? > > That's what I had in mind. It would be good if Thomas or

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

On Wed, Sep 14, 2016 at 12:08 PM, Christophe Lyon wrote: > On 14 September 2016 at 14:11, Andreas Schwab wrote: >> On Sep 13 2016, Jason Merrill wrote: >> >>> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

Hi Bernd, On Wed, Sep 14, 2016 at 04:01:34PM +0200, Bernd Schmidt wrote: > On 09/14/2016 03:55 PM, Segher Boessenkool wrote: > >On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: > >>The data that was posted showed a code size decrease on a number of > >>targets. I'm really not sure

Re: [PATCH] fix-it hints for warn_uninit

On 09/14/2016 05:34 AM, Bernd Schmidt wrote: On 09/14/2016 02:45 AM, David Malcolm wrote: In combination with -fdiagnostics-generate-patch this can generate output like this: --- ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c +++

[PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

Hi Jeff, it turned out, that the changed symmetric condition in the warning hit at several places, but also caused two false positives which I had to address first. I tried also building a recent glibc, which hit a false positive when using __builtin_isinf_sign in boolean context, which is used

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

uses exceptions. These examples worked for DJGPP as expected with today build of gcc-7.0.0-20160914. ZCX_By_Default in system-djgpp.ads had value true as in last version of patch. Andris

Re: [PATCH] Improve string::clear() performance

On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely wrote: > On 13/09/16 11:02 -0700, Cong Wang wrote: >> >> In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls >> _M_mutate(), which could allocate memory as we do COW. This hurts >> performance when string::clear()

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

On 14 September 2016 at 14:11, Andreas Schwab wrote: > On Sep 13 2016, Jason Merrill wrote: > >> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab >> wrote: >>> On Sep 13 2016, Jason Merrill wrote: >>> Does

Re: C++ PATCH to forbid use of bool with the ++ operator

On Tue, Sep 13, 2016 at 11:37:20PM -0400, Jason Merrill wrote: > On Tue, Sep 13, 2016 at 3:55 PM, Martin Sebor wrote: > > Having said all that, since this is C++ the message could and > > arguably should refer to a bool expression (or type) instead > > and avoid having to deal

Re: C/C++ PATCH to change {cp,}build_unary_op's parameter

On Wed, Sep 14, 2016 at 10:58:39AM -0400, Jason Merrill wrote: > On Wed, Sep 14, 2016 at 9:22 AM, Marek Polacek wrote: > > * c-common.h (build_unary_op): Change a parameter type to bool. > > (build_unary_op): Change a parameter type to bool, use true/false > >

Re: C++ PATCH to forbid use of bool with the ++ operator

On Wed, Sep 14, 2016 at 9:08 AM, Marek Polacek wrote: > On Tue, Sep 13, 2016 at 01:55:56PM -0600, Martin Sebor wrote: >> > - /* Forbid using -- on `bool'. */ >> > + /* Forbid using -- or ++ in C++17 on `bool'. */ >> > if (TREE_CODE (declared_type) == BOOLEAN_TYPE) >>

Re: C/C++ PATCH to change {cp,}build_unary_op's parameter

On Wed, Sep 14, 2016 at 9:22 AM, Marek Polacek wrote: > * c-common.h (build_unary_op): Change a parameter type to bool. > (build_unary_op): Change a parameter type to bool, use true/false > (cp_build_unary_op): Change a parameter type to bool. Use true

Re: C++ PATCH to forbid use of bool with the ++ operator

On Wed, Sep 14, 2016 at 10:54:35AM -0400, Jason Merrill wrote: > Martin's point, which I agree with, is that for C++ we want to use > "bool" rather than either of those. Sure, I'm testing another version of this patch which has this fixed. Marek

PR c++/77539

I've committed this backport to the gcc-6 branch. I'll commit the new testcase to trunk, so we don't regress in future. nathan 2016-09-14 Nathan Sidwell cp/ PR c++/77539 * constexpr.c (get_fundef_copy): Use the original function for non-recursive evaluations.

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 03:55 PM, Segher Boessenkool wrote: On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: The data that was posted showed a code size decrease on a number of targets. I'm really not sure where this irrational hate for regrename comes from. It increases the number of

Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments

On 09.08.2016 15:43, kugan wrote: Hi, The test-case in PR72835 is failing with -O2 and passing with -fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp. diff of .115t.dse2 and .116t.reassoc1 for the c++ testcase is as follows, which looks OK. + unsigned int _16; + unsigned int _17; +

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: > On 09/14/2016 03:04 PM, Segher Boessenkool wrote: > >Then rs6000 (and many other ports probably) will just turn it off again. > >It is actively harmful. > > The data that was posted showed a code size decrease on a number of >

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Wed, Sep 14, 2016 at 07:46:13AM -0500, Peter Bergner wrote: > On 9/14/16 5:35 AM, Segher Boessenkool wrote: > > (I hope the wording is strong enough). > Maybe s/New ports should use LRA/New ports must use LRA/ ? Yeah maybe. Does anyone else have an opinion on this? Cc:ing gcc@... > >+ New

Re: [PATCH] Optimize strchr (s, 0) to strlen

On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote: > > We've seen several different proposals for where/how to do this > > simplification, why did you > > say strlenopt is best? It would be an unconditional strchr (a, 0) -> a + > > strlen (a) rewrite, > > ie. completely unrelated to

Re: [PATCH] Optimize strchr (s, 0) to strlen

On Tue, Sep 13, 2016 at 2:36 PM, Wilco Dijkstra wrote: > Richard Biener wrote: >> On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra >> wrote: >>> Richard Biener wrote: >>> Yeah ;) I'm currently

Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate components

On Mon, Sep 12, 2016 at 12:02:50PM -0600, Jeff Law wrote: > >>>As a final optimisation, if a block needs a prologue and its immediate > >>>dominator has the block as a post-dominator, the dominator gets the > >>>prologue as well. > >>So why not just put it in the idom and not in the dominated

Re: [libstdc++-v3] Fix dg-require before dg-run directives in testsuite.

On 14 September 2016 at 15:27, Jonathan Wakely wrote: > On 14/09/16 15:17 +0200, Christophe Lyon wrote: >> >> It seems some tests still have dg-require or dg-skip before dg-do. >> The attached patch fixes that, the only effect is that >>

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On Wed, Sep 14, 2016 at 3:28 PM, Marek Polacek wrote: > On Wed, Sep 14, 2016 at 03:24:18PM +0200, Richard Biener wrote: >> > PING. >> > >> > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01837.html >> >> (that was a ping for the C FE maintainers) >> >> Prasad, can you update

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On Wed, Sep 14, 2016 at 03:24:18PM +0200, Richard Biener wrote: > > PING. > > > > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01837.html > > (that was a ping for the C FE maintainers) > > Prasad, can you update the git branch with the changes from the last patch you > sent out? I don't think

Re: [libstdc++-v3] Fix dg-require before dg-run directives in testsuite.

On 14/09/16 15:17 +0200, Christophe Lyon wrote: It seems some tests still have dg-require or dg-skip before dg-do. The attached patch fixes that, the only effect is that 25_algorithms/lower_bound/debug/irreflexive.cc is now UNSUPPORTED instead of PASS on arm* and aarch64* targets. I'm not sure

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On Fri, Sep 9, 2016 at 12:38 PM, Prasad Ghangal wrote: > On 26 August 2016 at 14:28, Richard Biener wrote: >> On Fri, Aug 26, 2016 at 5:08 AM, Prasad Ghangal >> wrote: >>> On 24 August 2016 at 15:32, Richard Biener

Re: [PATCH 6/9] sel-sched: Don't mess with register restores

On Mon, Sep 12, 2016 at 11:24:01AM -0600, Jeff Law wrote: > >sel-sched-ir.c says > > > >/* Certain instructions cannot be cloned, and frame related insns and > > the insn adjacent to NOTE_INSN_EPILOGUE_BEG cannot be moved out of > > their block. */ > >if

C/C++ PATCH to change {cp,}build_unary_op's parameter

I promised I'd do the int -> bool conversion for build_unary_op (and so even for cp_build_unary_op), so here it is. Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for trunk? 2016-09-14 Marek Polacek * c-common.c (c_common_truthvalue_conversion): Use

Re: [PATCH GCC 6/9]Simplify control flow graph for vectorized loop

On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote: > Hi, > This is the main patch improving control flow graph for vectorized loop. It > generally rewrites loop peeling stuff in vectorizer. As described in patch, > for a typical loop to be vectorized like: > >

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Mon, Sep 12, 2016 at 10:49:46AM -0600, Jeff Law wrote: > On 09/09/2016 02:56 PM, Segher Boessenkool wrote: > >On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote: > >>I think the lack of test coverage is something we'll want to address. > > > >Building and running the compiler, the various

Re: [libstdc++-v3] Fix dg-require before dg-run directives in testsuite.

On 6 September 2016 at 12:15, Jonathan Wakely wrote: > On 02/09/16 14:17 +0100, Matthew Wahab wrote: >> >> Hello, >> >> Tests in the libstdc++-v3 testsuite were recently changed to use { dg-do >> .. { target c++11 } } instead of using a dg-options to set -std >>

Re: C++ PATCH to forbid use of bool with the ++ operator

On Tue, Sep 13, 2016 at 01:55:56PM -0600, Martin Sebor wrote: > > - /* Forbid using -- on `bool'. */ > > + /* Forbid using -- or ++ in C++17 on `bool'. */ > > if (TREE_CODE (declared_type) == BOOLEAN_TYPE) > > { > > if (code == POSTDECREMENT_EXPR || code ==

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 03:04 PM, Segher Boessenkool wrote: Then rs6000 (and many other ports probably) will just turn it off again. It is actively harmful. The data that was posted showed a code size decrease on a number of targets. I'm really not sure where this irrational hate for regrename comes

Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote: > In an attempt to get this patch merged (as I still think that its > correct) I've investigated, and documented a little more about how I > think things currently work. I'm sure most people reading this will > already know this, but

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Mon, Sep 12, 2016 at 10:33:22AM -0600, Jeff Law wrote: > The answer is to debug the problem, and yes it may be painful. Yes, the three weeks pretty much full-time I spent on that already attest to that. > I'd > probably start by fixing the dataflow issues and see if that fixes the >

Re: [PATCH] Tree-level fix for PR 69526

On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote: >> if !inner_ovf (just set that to false if !check_inner_ovf to simplify >> checks please). >> you know it's valid to transform the op to (T)@0 innerop (T)@1 outerop @2 >> (if T is wider than the inner type which I think

Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

In an attempt to get this patch merged (as I still think that its correct) I've investigated, and documented a little more about how I think things currently work. I'm sure most people reading this will already know this, but hopefully, if my understanding is wrong someone can point it out. I've

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

On Wed, 2016-09-14 at 05:39 -0700, Ian Lance Taylor wrote: > On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote: > > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote: > >> I wonder about spelling the options as > >> -Wshadow={local,compatible-local} rather than with a

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 9/14/16 5:35 AM, Segher Boessenkool wrote: On Tue, Sep 13, 2016 at 02:38:54PM -0600, Jeff Law wrote: I believe a doc update of some kind is in order. With the doc update the entire series is OK. Good catch, thanks. My tests finished, all results identical. I'll add the following patch

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote: > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote: >> I wonder about spelling the options as >> -Wshadow={local,compatible-local} rather than with a dash, but >> otherwise the patch looks fine. > > That is a much nicer

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

On Mon, Sep 12, 2016 at 10:30:56AM -0600, Jeff Law wrote: > On 09/10/2016 01:17 AM, Segher Boessenkool wrote: > >On Fri, Sep 09, 2016 at 04:40:12PM -0600, Jeff Law wrote: > >>Right now the dataflow is conservatively correct WRT the return register. > > > >And conservatively incorrect wrt all other

Re: [Patch, Fortran] Test for implied sequence in structures in common blocks

Committed revision 240134. --- Fritz Reese On Tue, Sep 13, 2016 at 10:52 AM, Jerry DeLisle wrote: > On 09/13/2016 07:33 AM, Fritz Reese wrote: >> >> Jim, >> >> While the test exhibits no particular regression, IMVHO I don't see >> any reason not to add it. None of my

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

On 9/14/16, Jason Merrill wrote: > On Mon, Sep 12, 2016 at 1:38 PM, Jim Meyering wrote: >> On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager >> wrote: >>> On 9/11/16, Manuel López-Ibáñez wrote: On 11/09/16

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

On Sep 13 2016, Jason Merrill wrote: > On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab wrote: >> On Sep 13 2016, Jason Merrill wrote: >> >>> Does this help? >> >> Unfortunatly no. > > It occurs to me that this function doesn't need to

  1   2   >