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!
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 patch from July
> > > ( https://gcc.gnu.org/ml/gc
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 the patch
>>> >> accordingly.
>>> >> I have following questions
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 b
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
FMA (floating-point multiply-a
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 aarch64.
>>> These instructions
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 CC
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:
../../../gcc/libgo/go/u
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 I
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 frames
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 bug. I see no "vect"
option listed in the dump_op
On 10/13/2017 01:30 PM, Jakub Jelinek wrote:
> 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 i68
Hi!
First of all, there was a typo, we are optimizing
(x != 0) ? x + y : y
into x + y rather than y.
And, as the comment mentions, the condition that there is just a single
stmt is too restrictive and in the various patterns posted in the various
rotate related PRs there are cases where in additi
Hi!
The forwprop rotate pattern recognizer is able to detect various
patterns, but for the case where we want to support all rotate
counts without UB, it requires
Y &= B - 1;
R = (X << Y) | (X >> ((-Y) & (B - 1)));
where
R = (X << (Y & (B - 1))) | (X >> ((-Y) & (B - 1)));
is another reasonable way
> 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.c2017-10
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
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 19:15:11.4
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
Date: Fri Oct 1
> 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
This patch also caused a huge number of testsuite failures on PowerPC,
although it didn't break bootstrap.
Thanks, David
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 breaks
>> > building Chromium and Node.js.
>> > Fix
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 powerpc64le-l
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 default intialization of derived type arr
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
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
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 I
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 description of
>>> memo
[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 size
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.
>
> B
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.
>>
>>
>> 2017-09-05 Ur
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.
>
> htt
On 09/16/2017 03:39 PM, Bernhard Reutner-Fischer wrote:
> On 15 September 2017 18:50:26 CEST, Jeff Law wrote:
>> On 09/13/2017 03:20 PM, Wilco Dijkstra wrote:
>>> Jeff Law wrote:
On 09/06/2017 03:55 AM, Jackson Woodruff wrote:
> On 08/30/2017 01:46 PM, Richard Biener wrote:
>>>
>>
Dear All,
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.
Bootstraps and regtests of FC23/x86_64 - OK for trunk, 7- and 6-branches?
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
> Michael Collison
>
>
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 su
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
>
> * target-insns.def: Add memory_bloc
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 aarch64.
>> These instructions can produce different result if two operations executed
>> sep
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 on ppc64le.
> > Ok for tru
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 _M_sbu
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 STARTFIL
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
(--enable-check
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
> is different, overflow is if res
"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 modified by hand to
> include a sp
> 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 chime in
> as the
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 reassociation\n
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, I
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 m
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 subreg would preserve some of the existing conte
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 exp
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 go back to not doing typ
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 slightl
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 contents.
>>
>> combine does
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
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?
>
> Richa
> -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 Intel CET
>
> "Tsimbalist, Igor V" writes:
>
> >
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 happ
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.
>>> (test_range_functio
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: Likewise.
>> * configure: Like
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 powerpc64-linux-g
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 (bitmap_bit_in_range_p): F
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 a
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 Sandiford
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
gcc/
* inchash.h
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)
+++ cfghooks
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 switch statement in
> > built
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")
> > +
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 15:57:38
> Objet: Re: tree-complex.c: fix some_nonzerop test over reals (and a bug
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))
> +
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.
>>> (test_range_functio
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 m
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.
>> (sbitmap_c_tests): Lik
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");
>>
>> + if
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" {
> > ^~~
>
> Maybe a range spanning
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&&)): Ad
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
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
index
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 building libstdc++-v3 with Intel CET
>
> Enable
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
>> ( https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02084.html )
>>
>> One of the sticking points was what
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 ther
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
>> Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-im
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 'ary[inde
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))
> +
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 beca
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(&asanThreadRegistry());
>> +
>> +valid
> -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, 2017 at 8:54 PM, Tsimbalist, Igor
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
* graphite-i
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 la
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.
diff
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.
>
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg02026.html
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 unsigned arguments.
>
> Three
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 call the namespace; there was
> wariness about usi
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 powerpc intrinsics such as this
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 cha
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
+++ b/gcc/testsuite/c-c++-common/fcf-protect
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.
>> (sbitmap_c_tests): Lik
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
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, li
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 this change.
Thanks,
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!
I've held off installing the ap
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
> Subject: Re: [x86] GFNI enabling[1/4]
>
> On Fri, Oct 13, 2017 at 07:03:
1 - 100 of 103 matches
Mail list logo
