[PATCH] PR libstdc++/82481 Suppress clang-tidy warnings

Clang-tidy correctly notices that after exiting std:call_once a couple of globals are left pointing to local variables that go out of scope. This isn't a problem, because the globals are only ever used by std::call_once and it will re-init them before the next use. Zero the variables out just for

RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

> -Original Message- > From: Uros Bizjak [mailto:ubiz...@gmail.com] > Sent: Friday, October 13, 2017 10:02 AM > To: Tsimbalist, Igor V > Cc: gcc-patches@gcc.gnu.org > Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation > > On Thu, Oct 12,

RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET

Added libstd...@gcc.gnu.org > -Original Message- > From: Tsimbalist, Igor V > Sent: Thursday, October 12, 2017 10:24 PM > To: gcc-patches@gcc.gnu.org > Cc: Jeff Law ; jwak...@redhat.com; Tsimbalist, Igor V > > Subject: [PATCH 13/22] Enable

[PATCH] Document -fdump-tree-vect option

This adds an item to the list of options for the -fdump-tree option, because we show an example using 'vect' but don't document it. OK for trunk? Is there any logic to the order of those options? Would it makes sense to order them alphabetically? diff --git a/gcc/ChangeLog b/gcc/ChangeLog

[committed] C++: show location of unclosed extern "C" specifications (v3)

On Thu, 2017-10-12 at 17:07 -0400, Jason Merrill wrote: > On Thu, Oct 12, 2017 at 2:45 PM, David Malcolm > wrote: > > - put the note on the string-literal, rather than the extern: > > note: 'extern "C"' linkage started here > > extern "C" { > > ^~~ > >

Re: [PATCH] Fix bitmap_bit_in_range_p (PR tree-optimization/82493).

On 10/12/2017 11:54 PM, Jeff Law wrote: > On 10/11/2017 12:13 AM, Martin Liška wrote: >> 2017-10-10 Martin Liska >> >> PR tree-optimization/82493 >> * sbitmap.c (bitmap_bit_in_range_p): Fix the implementation. >> (test_range_functions): New function. >>

[PATCH][GRAPHITE] Consistently use region analysis

Now that SCEV instantiation handles regions properly (see hunk below for a minor fix) we can use it consistently from GRAPHITE and thus simplify scalar_evolution_in_region greatly. Bootstrap and regtest running on x86_64-unknown-linux-gnu. A lot of the parameter renaming stuff looks dead but a

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On Fri, Oct 13, 2017 at 02:53:50PM +0200, Martin Liška wrote: > @@ -3826,6 +3827,19 @@ pointer_diff (location_t loc, tree op0, tree op1) > pedwarn (loc, OPT_Wpointer_arith, >"pointer to a function used in subtraction"); > > + if (sanitize_flags_p (SANITIZE_POINTER_SUBTRACT)) >

[PATCH] PR libstdc++/82522 overload map insert functions for rvalues (LWG 2354)

DR 2354 adds these overloads to avoid unnecessary copies when doing map.insert({key, val}) PR libstdc++/82522 * doc/xml/manual/intro.xml: Document LWG 2354 changes. * include/bits/stl_map.h (map::insert(value_type&&)) (map::insert(const_iterator, value_type&&)):

Re: tree-complex.c: fix some_nonzerop test over reals (and a bug fix)

Hi Richard, I will investigate it further, but thanks again for your review! Laurent - Mail original - > De: "Richard Biener" > À: "Laurent Thevenoux" > Cc: "GCC Patches" > Envoyé: Lundi 9 Octobre 2017

Re: [PATCH] Add gnu::unique_ptr

On 10/13/2017 10:26 AM, Richard Biener wrote: > On Fri, Oct 13, 2017 at 2:40 AM, David Malcolm wrote: >> From: Trevor Saunders >> >> I had a go at updating Trevor's unique_ptr patch from July >> (

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On 10/13/2017 01:17 PM, Jakub Jelinek wrote: > On Fri, Oct 13, 2017 at 01:01:37PM +0200, Martin Liška wrote: >> @@ -3826,6 +3827,18 @@ pointer_diff (location_t loc, tree op0, tree op1) >> pedwarn (loc, OPT_Wpointer_arith, >> "pointer to a function used in subtraction"); >> >> +

Re: [PATCH] Improve rotate fold-const pattern matching (PR target/82498)

On Fri, 13 Oct 2017, Marc Glisse wrote: > On Fri, 13 Oct 2017, Richard Biener wrote: > > > On Thu, 12 Oct 2017, Jakub Jelinek wrote: > > > > > Hi! > > > > > > Marc in the PR mentioned that it is not really good that the recommended > > > rotate pattern is recognized only during forwprop1 and

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On Fri, Oct 13, 2017 at 01:01:37PM +0200, Martin Liška wrote: > @@ -3826,6 +3827,18 @@ pointer_diff (location_t loc, tree op0, tree op1) > pedwarn (loc, OPT_Wpointer_arith, >"pointer to a function used in subtraction"); > > + if (sanitize_flags_p (SANITIZE_POINTER_SUBTRACT)) >

[PATCH][GRAPHITE] Fix SSA update

This is something I wanted to do later just as compile-time optimization but it turns out it is necessary for correctness if we want to keep the current order of creating SCOPs and analyzing data references and parameters and only after that code-generating SCOPs that were optimized. This is

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On 10/12/2017 01:34 PM, Jakub Jelinek wrote: > On Thu, Oct 12, 2017 at 01:13:56PM +0200, Martin Liška wrote: >> + if (a1 == a2) >> +return; >> + >> + uptr shadow_offset1, shadow_offset2; >> + bool valid1, valid2; >> + { >> +ThreadRegistryLock l(()); >> + >> +valid1 =

[PATCH] Tree structure marking

In figuring out a problem with CODE_CONTAINS_STRUCT I noticed that: 1) the tree_contains_struct array is unsigned char. bool seems a better choice now we're in C++-land. 2) the MARK_TS_FOO macros used the 'do ... while (0)' idiom. But there's no need for such verbosity. These are

[PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

r253266 introduced a bogus "cannot bind bitfield" error that breaks building Chromium and Node.js. Fix by removing the ugly goto. Tested on ppc64le. Ok for trunk? Thanks. PR c++/82357 * typeck.c (build_static_cast): Handle processing_template_decl without using goto.

Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

On Fri, Oct 13, 2017 at 12:56 PM, Tsimbalist, Igor V wrote: >> -Original Message- >> From: Uros Bizjak [mailto:ubiz...@gmail.com] >> Sent: Friday, October 13, 2017 10:02 AM >> To: Tsimbalist, Igor V >> Cc: gcc-patches@gcc.gnu.org

Re: [PATCH] Tree structure marking

On Fri, 13 Oct 2017, Nathan Sidwell wrote: > In figuring out a problem with CODE_CONTAINS_STRUCT I noticed that: > > 1) the tree_contains_struct array is unsigned char. bool seems a better > choice now we're in C++-land. > > 2) the MARK_TS_FOO macros used the 'do ... while (0)' idiom. But

Re: [PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

On Fri, Oct 13, 2017 at 5:40 AM, Markus Trippelsdorf wrote: > r253266 introduced a bogus "cannot bind bitfield" error that breaks > building Chromium and Node.js. > Fix by removing the ugly goto. > > Tested on ppc64le. > Ok for trunk? No, this just undoes my change, so we

Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)

Hi, Sorry for the delay - I finally had a chance to look at this again. I'll start with alloca: @@ -15245,6 +15455,28 @@ aarch64_sched_can_speculate_insn (rtx_insn *insn) }  }   +/* It has been decided that to allow up to 1kb of outgoing argument +   space to be allocated w/o probing.  If

Re: [PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

On 2017.10.13 at 12:02 -0400, Jason Merrill wrote: > On Fri, Oct 13, 2017 at 5:40 AM, Markus Trippelsdorf > wrote: > > r253266 introduced a bogus "cannot bind bitfield" error that breaks > > building Chromium and Node.js. > > Fix by removing the ugly goto. > > > > Tested

Re: Add wider_subreg_mode helper functions

On 08/28/2017 02:26 AM, Richard Sandiford wrote: > This patch adds helper functions that say which of the two modes > involved in a subreg is the larger, preferring the outer mode in > the event of a tie. It also converts IRA and reload to track modes > instead of byte sizes, since this is

Re: [PATCH, Makefile] improve default cpu selection for e500v2

> On Oct 13, 2017, at 18:07 , Jeff Law wrote: > >>* gcc/config.gcc (powerpc*-*-*spe*): Pick 8548 as the >> default with_cpu for an e500v2 target cpu name, in addition >> to --enable-e500-double. > GIven this hits the powerpcspe port, I'd like Andrew Jenner to

Re: [PATCH] Fix __mulv[dt]i3 and expand_mul_overflow (PR target/82274)

On Fri, Sep 22, 2017 at 6:03 AM, Jakub Jelinek wrote: > > 2017-09-22 Jakub Jelinek > > PR target/82274 > * internal-fn.c (expand_mul_overflow): If both operands have > the same highpart of -1 or 0 and the topmost bit of lowpart >

Check that there are no missing probabilities

Hi, this patch enables check that no edge probabilities are missing. Honza * cfghooks.c (verify_flow_info): Check that edge probabilities are set. Index: cfghooks.c === --- cfghooks.c (revision 253694) +++

Rename inchash::hash::add_wide_int

The name inchash::add_wide_int is a bit misleading, since it sounds like it's hashing a wide_int. This patch renames it to add_hwi instead. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. OK to install? Richard 2017-10-13 Richard Sandiford

Re: [PATCH] Fix bitmap_bit_in_range_p (PR tree-optimization/82493).

On 10/13/2017 07:03 AM, Martin Liška wrote: > On 10/13/2017 10:01 AM, Martin Liška wrote: >> On 10/12/2017 11:54 PM, Jeff Law wrote: >>> On 10/11/2017 12:13 AM, Martin Liška wrote: 2017-10-10 Martin Liska PR tree-optimization/82493 * sbitmap.c

Re: Make more use of df_read_modify_subreg_p

On 08/24/2017 12:25 PM, Richard Sandiford wrote: > Segher Boessenkool writes: >> On Wed, Aug 23, 2017 at 11:49:03AM +0100, Richard Sandiford wrote: >>> This patch uses df_read_modify_subreg_p to check whether writing >>> to a subreg would preserve some of the existing

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On 09/06/2017 03:26 AM, Jakub Jelinek wrote: > On Tue, Sep 05, 2017 at 11:21:48PM -0600, Jeff Law wrote: >> --- a/gcc/tree-ssa-reassoc.c >> +++ b/gcc/tree-ssa-reassoc.c >> @@ -5763,14 +5763,15 @@ reassociate_bb (basic_block bb) >> "Width = %d was chosen for

Re: [PATCH 09/22] Enable building libbacktrace with Intel CET

"Tsimbalist, Igor V" writes: > > This file is included to simplify building a library that might have > assembler files. > This is an auxiliary file to automate creation of a special section in > an output object > file. Without it every assembler file has to be

Re: Check that there are no missing probabilities

On Fri, Oct 13, 2017 at 03:38:33PM +0200, Jan Hubicka wrote: > Hi, > this patch enables check that no edge probabilities are missing. > > Honza > > * cfghooks.c (verify_flow_info): Check that edge probabilities are > set. This broke bootstrap on x86_64-linux with Ada

Re: [PATCH, alpha] Move linux-specific specfile definitions to linux.h

On 09/03/2017 09:47 AM, Maya Rashish wrote: > Hi, in my first attempt to fix a build issue I found that the order of > tm files matters, would prefer to move linux-looking parts of elf.h to > linux.h. > > other targets that include alpha/elf.h besides linux: > openbsd: provides their own

Re: [PATCH, Makefile] improve default cpu selection for e500v2

On 08/31/2017 12:54 PM, Olivier Hainque wrote: > Hello, > > gcc can be configured with an "e500v2" cpu target > name, conveying SPE with double precision floats. > > config.gcc already has a provision for a good default > cpu selection for SPE with double precision floats > when the latter is

Re: Make more use of df_read_modify_subreg_p

Jeff Law writes: > On 08/24/2017 12:25 PM, Richard Sandiford wrote: >> Segher Boessenkool writes: >>> On Wed, Aug 23, 2017 at 11:49:03AM +0100, Richard Sandiford wrote: This patch uses df_read_modify_subreg_p to check whether writing to a

[RFC, PR 80689] Copy small aggregates element-wise

Hi, I'd like to request comments to the patch below which aims to fix PR 80689, which is an instance of a store-to-load forwarding stall on x86_64 CPUs in the Image Magick benchmark, which is responsible for a slow down of up to 9% compared to gcc 6, depending on options and HW used. (Actually,

Make istreambuf_iterator::_M_sbuf immutable and add debug checks

Hi     Here is the last patch I will propose for istreambuf_iterator. This is mostly to remove the mutable keyword on _M_sbuf.     To do so I had to reset _M_sbuf in valid places that is to say constructors and increment operators. Despite that we might still have eof iterators with

Re: Check that there are no missing probabilities

On Fri, Oct 13, 2017 at 6:38 AM, Jan Hubicka wrote: > Hi, > this patch enables check that no edge probabilities are missing. This caused a bootstrap failure on aarch64-linux-gnu with go enabled. But I see you have disabled the code for now. Just for reference the failure:

Re: [PATCH] rl78 adddi3 improvement

Sebastian Perta writes: > Please let me know if this is OK, Thank you! Sorry for the delay, it's OK and I committed it for you with a few minor changes to make it work with today's tree. Thanks!

Re: [PATCH, rs6000] GIMPLE folding for vector compares

On Thu, 2017-10-12 at 22:05 -0500, Segher Boessenkool wrote: > > diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md > > > +;; Vector Compare Not Equal Byte (specified/not+eq:) > > +(define_insn "vcmpneb_spec" > > + [(set (match_operand:V16QI 0 "altivec_register_operand" "=v") > > +

Re: [PATCH, rs6000] GIMPLE folding for vector compares

On Fri, 2017-10-13 at 11:36 +0200, Richard Biener wrote: > On Thu, Oct 12, 2017 at 10:03 PM, Will Schmidt > wrote: > > Hi, > > > > Add support for gimple folding of vec_cmp_{eq,ge,gt,le,ne} for > > the integer data types. > > > > This adds a handful of entries to the

Add wide_int version of inchash::hash::add_wide_int

This patch adds an inchash hasher for wide_int-based types. It means that hash_tree no longer hashes TREE_INT_CST_EXT_NUNITS, but that was redundant with hashing the type. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64-linux-gnu. OK to install? Richard 2017-10-13 Richard

Re: [PATCH 09/22] Enable building libbacktrace with Intel CET

On 10/12/2017 05:58 PM, Ian Lance Taylor wrote: > "Tsimbalist, Igor V" writes: > >> Enable building libbacktrace with CET options. >> >> libbacktrace/ >> * configure.ac: Add CET_FLAGS to EXTRA_FLAGS. >> * aclocal.m4: Regenerate. >> * Makefile.in:

Re: [PATCH] Fix bitmap_bit_in_range_p (PR tree-optimization/82493).

On 10/13/2017 07:02 AM, Martin Liška wrote: > On 10/12/2017 11:54 PM, Jeff Law wrote: >> On 10/11/2017 12:13 AM, Martin Liška wrote: >>> 2017-10-10 Martin Liska >>> >>> PR tree-optimization/82493 >>> * sbitmap.c (bitmap_bit_in_range_p): Fix the implementation. >>>

Re: Rename inchash::hash::add_wide_int

On 10/13/2017 08:04 AM, Richard Sandiford wrote: > The name inchash::add_wide_int is a bit misleading, since it sounds > like it's hashing a wide_int. This patch renames it to add_hwi instead. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. > OK to install? > >

Re: [PING from 2013][PATCH] fixincludes: handle symlinks with multiple slashes

On 08/17/2017 02:31 PM, Sergei Trofimovich wrote: > Looks like the following patch falled through the cracks > https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01397.html > https://bugs.gentoo.org/show_bug.cgi?id=434180#c16 Yea. Looks like it did fall through the cracks. I've updated Mike's

Add an alternative vector loop iv mechanism

Normally we adjust the vector loop so that it iterates: (original number of scalar iterations - number of peels) / VF times, enforcing this using an IV that starts at zero and increments by one each iteration. However, dividing by VF would be expensive for variable VF, so this patch adds an

[PATCH GCC]Try harder to find base object by expanding base address

Hi, I ran into this when investigating PR82369 which we failed to find base object. This simple patch tries harder to find base object by expanding base address in alloc_iv. In general, we don't want to do aggressive expansion, but this case is fine because finding base object means reduction

RE: [PATCH 09/22] Enable building libbacktrace with Intel CET

> -Original Message- > From: Ian Lance Taylor [mailto:i...@airs.com] > Sent: Friday, October 13, 2017 1:59 AM > To: Tsimbalist, Igor V > Cc: gcc-patches@gcc.gnu.org; Jeff Law > Subject: Re: [PATCH 09/22] Enable building libbacktrace with

Re: Add wide_int version of inchash::hash::add_wide_int

On 10/13/2017 08:05 AM, Richard Sandiford wrote: > This patch adds an inchash hasher for wide_int-based types. > It means that hash_tree no longer hashes TREE_INT_CST_EXT_NUNITS, > but that was redundant with hashing the type. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and

Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)

Hi, To continue the review of the AArch64 frame code I tried a few examples to figure out what it does now. For initial_adjust <= 63*1024 and final_adjust < 1024 there are no probes inserted as expected, ie. the vast majority of functions are unaffected. So that works perfectly. For larger

Re: [PATCH] Document -fdump-tree-vect option

On 13/10/17 14:06 -0600, Sandra Loosemore wrote: On 10/13/2017 06:35 AM, Jonathan Wakely wrote: This adds an item to the list of options for the -fdump-tree option, because we show an example using 'vect' but don't document it. OK for trunk? No, I think this patch is addressing an imaginary

Re: [PATCH 2/2] PR libgcc/59714 complex division is surprising on aarch64

On Fri, Oct 13, 2017 at 10:25 PM, Richard Earnshaw wrote: > On 13/10/17 18:28, vladimir.mezent...@oracle.com wrote: >> On 10/12/2017 03:40 AM, Richard Earnshaw wrote: >>> On 12/10/17 06:21, vladimir.mezent...@oracle.com wrote: From: Vladimir Mezentsev

[PATCH] Implement unique_xmalloc_ptr<T[]> and add more selftests

On Fri, 2017-10-13 at 13:01 +0100, Pedro Alves wrote: > On 10/13/2017 10:26 AM, Richard Biener wrote: > > On Fri, Oct 13, 2017 at 2:40 AM, David Malcolm > > wrote: > > > From: Trevor Saunders > > > > > > I had a go at updating Trevor's unique_ptr

Re: [PATCH 2/2] PR libgcc/59714 complex division is surprising on aarch64

On 13/10/17 18:28, vladimir.mezent...@oracle.com wrote: > On 10/12/2017 03:40 AM, Richard Earnshaw wrote: >> On 12/10/17 06:21, vladimir.mezent...@oracle.com wrote: >>> From: Vladimir Mezentsev >>> >>> FMA (floating-point multiply-add) instructions are supported on

Zen tuning part 8: Fix rtx costs.

Hi, this patch fixes costs of basic operations for Zen. It also models SSE more carefully. ix86_rtx_costs is still based on x87 costs of operations which is not very realistic today when x87 and SSE costs are often quite different. The latencies in this patch are based on Agner Fog's values and

Re: Make more use of df_read_modify_subreg_p

On Fri, Oct 13, 2017 at 05:08:51PM +0100, Richard Sandiford wrote: > Yeah, I agree this'll change the handling of paradoxical subregs that > occupy more words than the SUBREG_REG, but I think the new version is > correct. The comment says: > > /* If the destination is anything other than

Re: [RFC] propagate malloc attribute in ipa-pure-const pass

On 7 October 2017 at 12:35, Prathamesh Kulkarni wrote: > On 7 October 2017 at 11:23, Jan Hubicka wrote: >>> On 6 October 2017 at 06:04, Jan Hubicka wrote: >>> >> Hi Honza, >>> >> Thanks for the detailed suggestions, I have updated

Re: [PATCH, rs6000] GIMPLE folding for vector compares

On Thu, Oct 12, 2017 at 10:03 PM, Will Schmidt wrote: > Hi, > > Add support for gimple folding of vec_cmp_{eq,ge,gt,le,ne} for > the integer data types. > > This adds a handful of entries to the switch statement in > builtin_function_type > for those builtins having

Re: [PATCH 4/9] [SFN] introduce statement frontier notes, still disabled

On Fri, Oct 13, 2017 at 9:21 AM, Alexandre Oliva wrote: > On Oct 9, 2017, Richard Biener wrote: > >> The middle-end changes are ok. The C FE change looks reasonable, >> I'd appreciate a 2nd look at the C++ FE changes by a maintainer. > >

Re: SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn

On 09/20/2017 06:21 AM, Richard Sandiford wrote: > This is needed by the later SVE LAST reductions, where an 8-bit > or 16-bit result is zero- rather than sign-extended to 32 bits. > I think it could occur in other situations too. > > Tested on aarch64-linux-gnu, x86_64-linux-gnu and

Re: [PATCH C++] Fix PR82357 - bogus "cannot bind bitfield" error

On Fri, Oct 13, 2017 at 1:21 PM, Markus Trippelsdorf wrote: > On 2017.10.13 at 12:02 -0400, Jason Merrill wrote: >> On Fri, Oct 13, 2017 at 5:40 AM, Markus Trippelsdorf >> wrote: >> > r253266 introduced a bogus "cannot bind bitfield" error that

Re: Check that there are no missing probabilities

This patch also caused a huge number of testsuite failures on PowerPC, although it didn't break bootstrap. Thanks, David

Re: Check that there are no missing probabilities

> On Fri, Oct 13, 2017 at 03:38:33PM +0200, Jan Hubicka wrote: > > Hi, > > this patch enables check that no edge probabilities are missing. > > > > Honza > > > > * cfghooks.c (verify_flow_info): Check that edge probabilities are > > set. > > This broke bootstrap on x86_64-linux with

[committed][PATCH] Trivial cleanup in tree-ssa-reassoc.c

Jakub spotted this wart in my last change.We have already tested that we do not have 0 or 1 ops. So != 2 is more clearly written as > 2. Bootstrapped and regression tested on x86_64. Committed to the trunk. Jeff commit 04acc76e9d46299f5251bf9f495d1b7688d7907f Author: law

Re: Check that there are no missing probabilities

On Fri, Oct 13, 2017 at 09:06:55PM +0200, Jan Hubicka wrote: > For EH we should set it to profile_probability::zero () because we know it is > unlikely > path. I will take a look. With the --- gcc/cfghooks.c.jj 2017-10-13 18:27:12.0 +0200 +++ gcc/cfghooks.c 2017-10-13

[C/C++ PATCH] Handle rotates like shifts

Hi! I've noticed that for {L,R}ROTATE_EXPR created during GENERIC folding we end up with e.g. long int etc. second arguments, while for shifts we truncate those to unsigned int. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-10-13 Jakub Jelinek

Re: Check that there are no missing probabilities

> On Fri, Oct 13, 2017 at 09:06:55PM +0200, Jan Hubicka wrote: > > For EH we should set it to profile_probability::zero () because we know it > > is unlikely > > path. I will take a look. > > With the > > --- gcc/cfghooks.c.jj 2017-10-13 18:27:12.0 +0200 > +++ gcc/cfghooks.c

Re: [PATCH] Improve x86 and + rotate (PR target/82498)

On Thu, Oct 12, 2017 at 9:11 PM, Jakub Jelinek wrote: > On Thu, Oct 12, 2017 at 10:40:22AM +0200, Uros Bizjak wrote: >> > So, if you aren't against it, I can extend the patch to handle the 4 >> > other mask patterns; as for other modes, SImode is what is being handled >> >

Re: [PATCH] Fix various arithmetic patterns with %[abcd]h destination (PR target/82524)

On Thu, Oct 12, 2017 at 9:49 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, there are two bugs in these. One is that > the zero_extract destination is effectively another input operand (for the > remaining bits that are unchanged) and thus the constraint can't be

Re: [PATCH] Avoid UB in ia32intrin.h rotate patterns (PR target/82498)

On Thu, Oct 12, 2017 at 9:39 PM, Jakub Jelinek wrote: > Hi! > > The ia32intrin.h rotate intrinsics require the second argument to be > in between 1 and 31 (or 63), otherwise they invoke UB. But, we can do much > better while generating the same instruction when optimizing, so

Re: 0004-Part-4.-Update-x86-backend-to-enable-Intel-CET

On Thu, Oct 12, 2017 at 8:45 PM, Tsimbalist, Igor V wrote: > Uros, > > Attached is an updated patch. The main difference is in option name and > attribute name change. Other code is the same. Trivial changes (if they fall under "trivial" rule) don't need extra

[x86] GFNI enabling[1/4]

Hi, gcc/ * gcc/common/config/i386/i386-common.c (OPTION_MASK_ISA_GFNI_SET, (OPTION_MASK_ISA_GFNI_UNSET): New. (ix86_handle_option): Handle OPT_mgfni. * gcc/config/i386/cpuid.h (bit_GFNI): New. * gcc/config/i386/driver-i386.c (host_detect_local_cpu): Detect

Re: [x86] GFNI enabling[1/4]

On Fri, Oct 13, 2017 at 07:03:14AM +, Koval, Julia wrote: --- a/gcc/config/i386/i386.opt +++ b/gcc/config/i386/i386.opt @@ -753,6 +753,10 @@ mrdpid Target Report Mask(ISA_RDPID) Var(ix86_isa_flags2) Save Support RDPID built-in functions and code generation. +mgfni +Target Report

Re: [PATCH] i386: Check red zone size in push peephole2

On Wed, Oct 11, 2017 at 3:16 AM, H.J. Lu wrote: > Check red zone size, instead of if red zone is available, in push > peephole2s. > > Tested on i686 and x86-64. OK for master? Please rename variable to ix86_red_zone_size, as Jakub suggested in the PR. OK for mainline with

[ARM] PR 67591 ARM v8 Thumb IT blocks are deprecated part 2

Hi, The attached small patch solves PR 67591 and removes occurrences of "IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8". It is similar to the patch I committed recently and updates the 3 remaining patterns that can generate such instructions. I checked gcc.log, g++.log,

Re: [PATCH] Fix bitmap_bit_in_range_p (PR tree-optimization/82493).

On 10/12/2017 11:54 PM, Jeff Law wrote: > On 10/11/2017 12:13 AM, Martin Liška wrote: >> 2017-10-10 Martin Liska >> >> PR tree-optimization/82493 >> * sbitmap.c (bitmap_bit_in_range_p): Fix the implementation. >> (test_range_functions): New function. >>

Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

On Thu, Oct 12, 2017 at 8:54 PM, Tsimbalist, Igor V wrote: > Attached is an updated patch according to your comments. New tests are > added to test ICF optimization in presence of nocf_check attribute. --- a/gcc/testsuite/c-c++-common/fcf-protection-2.c +++

Re: [PATCH] Improve rotate fold-const pattern matching (PR target/82498)

On Thu, 12 Oct 2017, Jakub Jelinek wrote: > Hi! > > Marc in the PR mentioned that it is not really good that the recommended > rotate pattern is recognized only during forwprop1 and later, which is after > einline and that inlining or early opts could have changed stuff too much so > that we

RE: [x86] GFNI enabling[1/4]

Sorry, fixed that. Thanks, Julia > -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Friday, October 13, 2017 9:08 AM > To: Koval, Julia > Cc: GCC Patches ; Uros Bizjak > ; Kirill Yukhin

Re: [PATCH 4/9] [SFN] introduce statement frontier notes, still disabled

On Oct 9, 2017, Richard Biener wrote: > The middle-end changes are ok. The C FE change looks reasonable, > I'd appreciate a 2nd look at the C++ FE changes by a maintainer. https://gcc.gnu.org/ml/gcc-patches/2017-09/msg02026.html Thanks a lot for the reviews!

Patch ping^3

Hi! I'd like to ping the following wrong-code patch: http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01540.html libgcc __mulvDI3 fix - missed detection of overflow for

Re: Ping for some "make more use of ..." patches

On 09/18/2017 10:29 AM, Richard Sandiford wrote: > Ping for some minor cleanups that help with the move to variable-length > modes. Segher has approved the combine.c parts (thanks). > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01339.html > Make more use of HWI_COMPUTABLE_MODE_P OK. > >

Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern

On Fri, Oct 13, 2017 at 7:30 PM, Jeff Law wrote: > On 09/05/2017 07:50 AM, Uros Bizjak wrote: >> Revised patch, incorporates fixes from Alexander's review comments. >> >> I removed some implementation details from Alexander's description of >> memory_blockage named pattern. >> >>

Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern

On 10/13/2017 12:27 PM, Uros Bizjak wrote: > On Fri, Oct 13, 2017 at 7:30 PM, Jeff Law wrote: >> On 09/05/2017 07:50 AM, Uros Bizjak wrote: >>> Revised patch, incorporates fixes from Alexander's review comments. >>> >>> I removed some implementation details from Alexander's

Re: Base subreg rules on REGMODE_NATURAL_SIZE rather than UNITS_PER_WORD

On 09/18/2017 05:26 AM, Richard Sandiford wrote: > Originally subregs operated at the word level and subreg offsets > were measured in words. The offset units were later changed from > words to bytes (SUBREG_WORD became SUBREG_BYTE), but the fundamental > assumption that subregs should operate at

Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern

On 09/05/2017 07:50 AM, Uros Bizjak wrote: > Revised patch, incorporates fixes from Alexander's review comments. > > I removed some implementation details from Alexander's description of > memory_blockage named pattern. > > > 2017-09-05 Uros Bizjak > > *

Re: [PATCH][compare-elim] Merge zero-comparisons with normal ops

On 09/06/2017 09:56 AM, Michael Collison wrote: > Patch updated with all relevant comments and suggestions. > > Bootstrapped and tested on arm-none-linux-gnueabihf, and > aarch64-none-linux-gnu and x86_64. > > Ok for trunk? > > 2017-08-05 Kyrylo Tkachov >

[PATCH,RFC] collect2 LTO for AIX

The attached patch is an incremental step toward GCC LTO on AIX. The recent Libiberty Simple Object improvements for XCOFF provide more capabilities for operations on XCOFF object files, which are a prerequisite for GCC LTO functionality. This patch adds the basic LTO scanning pass to the COFF

Re: [Patch, fortran] PR81048 - [6/7/8 Regression] incorrect derived type initialization

On Fri, Oct 13, 2017 at 07:06:57PM +0100, Paul Richard Thomas wrote: > > This patch undoes a side effect of r225447 that had the effect of > eliminating the default intialization of derived type array results. > > The patch corrects the offending changes to the condition in resolve_symbol. > >

[PATCH PR/82546] tree node size

[Although I filed this as a middle-end bug, it's really a core infra bug, not sure who the best reviewer is] In working on tree streaming in the modules branch, I discovered poor tree node size and hierarchy bits. Here's a fix for the first part of that. tree.c (tree_code_size) returns

Re: patch to fix PR82353

On 10/12/2017 10:49 AM, Jakub Jelinek wrote: > Hi! > > On Wed, Oct 11, 2017 at 06:41:05PM -0400, Vladimir Makarov wrote: >>> Tested on x86_64-linux -m32/-m64, and verified with cc1plus before your >>> change, ok for trunk? > > BTW, I think it is quite fragile to scan for the reload messages, so

Re: [Patch, fortran] PR81048 - [6/7/8 Regression] incorrect derived type initialization

Good you caught the missing LF. Thanks! Paul On 13 October 2017 at 19:29, Steve Kargl wrote: > On Fri, Oct 13, 2017 at 07:06:57PM +0100, Paul Richard Thomas wrote: >> >> This patch undoes a side effect of r225447 that had the effect of >> eliminating the

Re: [PATCH] Factor out division by squares and remove division around comparisons (1/2)

Jeff Law wrote: >> Btw reminds me a little bit of >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 > I wouldn't expect 28417 > to move forward without something other than Tege and Denys pushing on it. Hmm that doesn't look optimal. You can typically do a multiply with the magic constant

Re: [PATCH] Improve rotate fold-const pattern matching (PR target/82498)

On Fri, 13 Oct 2017, Richard Biener wrote: On Thu, 12 Oct 2017, Jakub Jelinek wrote: Hi! Marc in the PR mentioned that it is not really good that the recommended rotate pattern is recognized only during forwprop1 and later, which is after einline and that inlining or early opts could have

Re: [PATCH] (gimple) Allow integer return type from vector compares

On Thu, Oct 12, 2017 at 10:02 PM, Will Schmidt wrote: > Hi, > > Update the logic in verify_gimple_comparision to allow a vector integer result > from a vector comparison, where it previously was limited to only allowing > compares with boolean results. This allows

Re: [PATCH] Add gnu::unique_ptr

On Fri, Oct 13, 2017 at 2:40 AM, David Malcolm wrote: > From: Trevor Saunders > > I had a go at updating Trevor's unique_ptr patch from July > ( https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02084.html ) > > One of the sticking points was what to

[PATCH][GRAPHITE] Some TLC

Removing a global constructor, a return value that isn't checked and adjusting testcases that spew -Waggressive-loop-optimization warnings when built with different options. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-10-13 Richard Biener

Re: [PATCH] Fix bitmap_bit_in_range_p (PR tree-optimization/82493).

On 10/13/2017 10:01 AM, Martin Liška wrote: > On 10/12/2017 11:54 PM, Jeff Law wrote: >> On 10/11/2017 12:13 AM, Martin Liška wrote: >>> 2017-10-10 Martin Liska >>> >>> PR tree-optimization/82493 >>> * sbitmap.c (bitmap_bit_in_range_p): Fix the implementation. >>>

  1   2   >