Re: [PATCH 2/6] Fix memory leak in tree-ssa

On 11/23/2015 02:48 PM, marxin wrote: gcc/ChangeLog: 2015-11-20 Martin Liska * tree-ssa.c (redirect_edge_var_map_destroy): Release vectors that are used as a second argument of a hash_map. --- gcc/tree-ssa.c | 5 + 1 file changed, 5 insertions(+) diff

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

On 11/26/2015 09:53 PM, Martin Liška wrote: Is the patch still candidate to be merged in current stage3, or should I leave it to the next stage1? What about the first patch or the patch, where I just applied replacement of whitespaces? As I said previously, the one to just replace whitespace

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

On 11/20/2015 12:15 PM, Martin Liška wrote: On 11/20/2015 03:14 AM, Bernd Schmidt wrote: BTW, I'm with whoever said absolutely no way to the idea of making automatic changes like this as part of a commit hook. I think the whitespace change can go in if it hasn't already, but I think the

Re: [PATCH 3/6] Fix memory leaks in IPA devirt

On 11/23/2015 11:29 PM, Trevor Saunders wrote: On Mon, Nov 23, 2015 at 02:48:37PM +0100, marxin wrote: gcc/ChangeLog: 2015-11-20 Martin Liska * ipa-devirt.c (ipa_devirt): Use auto_vec instead of a local-scope vec. Release final_warning_records. ---

RE: [PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches='

On Thu, 26 Nov 2015, Moore, Catherine wrote: > > OK to apply? > > > Yes -- thanks. Applied, thanks for your review. Maciej

fix formatting

I checked this in to fix a formatting issue. != binds more tightly than &&. Index: lra-constraints.c === --- lra-constraints.c (revision 230982) +++ lra-constraints.c (working copy) @@ -2556,8 +2556,8 @@ process_alt_operands

Re: [PATCH 1/6] Fix memory leak in cilk

On 11/23/2015 02:48 PM, marxin wrote: gcc/c/ChangeLog: 2015-11-20 Martin Liska PR c++/68312 * c-array-notation.c (fix_builtin_array_notation_fn): Use release_vec_vec instead of vec::release. (build_array_notation_expr): Likewise.

[PATCH 7/N] Fix newly introduced memory leak in tree-ssa-loop-ivopts.c

Hi. There's one more patch that fixes really of lot memory leaks related to loop ivopts. The regression was introduced by r230647. Patch was tested in the series with the rest and the compiler bootstraps successfully. Ready for trunk? Thanks, Martin >From

[PR67335] drop dummy zero from reverse VTA ops, fix infinite recursion

VTA's cselib expression hashing compares expressions with the same hash before adding them to the hash table. When there is a collision involving a self-referencing expression, we could get infinite recursion, in spite of the cycle breakers already in place. The problem is currently latent in

Re: [PR67335] drop dummy zero from reverse VTA ops, fix infinite recursion

On Nov 26, 2015, Alexandre Oliva wrote: > for gcc/ChangeLog > PR debug/67355 > * var-tracking.c (reverse_op): Don't add dummy zero to reverse > ops that simplify back to the original value. > * alias.c (refs_newer_value_p): Cut off recursion for >

Re: [PATCH 7/N] Fix newly introduced memory leak in tree-ssa-loop-ivopts.c

On Fri, Nov 27, 2015 at 5:08 AM, Martin Liška wrote: > Hi. > > There's one more patch that fixes really of lot memory leaks related to loop > ivopts. > The regression was introduced by r230647. > > Patch was tested in the series with the rest and the compiler bootstraps >

[patch] Fix PR c++/68290

Hi, this is a variant of the just fixed PR c++/68434 on SPARC64/Solaris: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/concepts/auto1.C:16:6: internal compiler error: canonical types differ for identical types C and C with the same underlying issue, which is that TYPE_CANONICAL is computed

Re: [PING] Re: [PATCH] c++/67913, 67917 - fix new expression with wrong number of elements

On 11/26/2015 10:45 AM, Martin Sebor wrote: On 11/26/2015 04:33 AM, Ramana Radhakrishnan wrote: Cookies on ARM are 8-bytes [1], but sizeof ((size_t) n) is only 4-bytes, so this check will fail (We'll ask for 500 bytes, the test here will only be looking for 496). Would it undermine the test

Re: Fix verify_type ICE during Ada bootstrap

> On Tue, 24 Nov 2015, Jan Hubicka wrote: > > > > > > > > > We do already wrap all bases into MEM_REFs at streaming time, it would > > > > be easy to adjust it to make it effectively alias-set zero. But of > > > > course the overhead and the downstream effects of having more MEM_REFs > > > >

RE: Fix 61441

Hi, > I think the general principle is: > > * The caller decides whether folding is desirable (whether it would lose > exceptions, for example). > > * The real.c code is called only when the caller has decided that folding is > desirable, and should always produce the correct output (which for

Fix 61441 [ 1/5] Add REAL_VALUE_ISSIGNALING_NAN

Hi, This series of patches fixes PR61441. The fix is broken into 5 patches. The first one adds REAL_VALUE_ISSIGNALING_NAN. 2015-11-26 Sujoy Saraswati PR tree-optimization/61441 * real.c (real_issignaling_nan): New. * real.h

Fix 61441 [2/5] Use REAL_VALUE_ISSIGNALING_NAN instead of REAL_VALUE_ISNAN where appropriate

This patch uses REAL_VALUE_ISSIGNALING_NAN instead of REAL_VALUE_ISNAN to avoid the operation for sNaN. Regards, Sujoy 2015-11-26 Sujoy Saraswati PR tree-optimization/61441 * fold-const.c (const_binop): Use REAL_VALUE_ISSIGNALING_NAN

Fix 61441 [3/5] Remove flag_errno_math check for RINT

Hi, This patch removes flag_errno_math check for RINT, treating it similar to nearbyint. Regards, Sujoy 2015-11-26 Sujoy Saraswati PR tree-optimization/61441 * match.pd (f(x) -> x): Removed flag_errno_math check for RINT. Index:

Fix 61441 [4/5] Produce quiet NaN for real value operations

Hi, This patch makes resulting NaN values to be quiet NaN for real value operations, irrespective of the flag_signaling_nans flag. The caller has the responsibility to avoid the operation if flag_signaling_nans is on. Regards, Sujoy 2015-11-26 Sujoy Saraswati

Fix 61441 [5/5] Disable various transformations for signaling NaN operands

Hi, This patch avoids various transformations with signaling NaN operands when flag_signaling_nans is on, to avoid folding which would lose exceptions. A test case for this change is also added as part of this patch. Regards, Sujoy 2015-11-26 Sujoy Saraswati

Re: RFC: C++ delayed folding merge

Hi! On Mon, 9 Nov 2015 01:30:34 -0500, Jason Merrill wrote: > I'm planning to merge the C++ delayed folding branch this week [...] In r230554, , Cesar already fixed up cp_fold_r to also

Re: [PATCH] Convert manual unsigned +/- overflow checking into {ADD,SUB}_OVERFLOW (PR target/67089)

On Wed, 25 Nov 2015, Marc Glisse wrote: > On Wed, 25 Nov 2015, Jakub Jelinek wrote: > > > > The same is true whether we write it b > a or (a - b) > a (I don't think > > > PRE > > > + SCCVN avoid increasing register pressure). > > > > > > > So, I'd really prefer doing x-y>x to y>x only for

[gomp4] Merge trunk r230627 (2015-11-19) into gomp-4_0-branch

Hi! Committed to gomp-4_0-branch in r230925: commit 3ce2a2ee891a51909c23b2cb1a13f230c6a75e36 Merge: d60891e 62efaf6 Author: tschwinge Date: Thu Nov 26 09:02:30 2015 + svn merge -r 230275:230627 svn+ssh://gcc.gnu.org/svn/gcc/trunk

Re: GCC 5.3 Status Report (2015-11-20)

On Wed, Nov 25, 2015 at 7:59 PM, David Edelsohn wrote: > On Wed, Nov 25, 2015 at 11:57 AM, Paolo Bonzini wrote: > >> Patch committed to upstream libtool, thanks for your understanding. > > Great! > > How can I have the patch backported to GCC trunk and

Re: RFA: PATCH to gimple_canonical_types_compatible_p for middle-end/66214

On Wed, Nov 25, 2015 at 4:55 PM, Jason Merrill wrote: > The problem here is that we're trying to compare the TYPE_FIELDS of two > variants of an incomplete type, which doesn't make sense; we shouldn't > expect TYPE_FIELDS of an incomplete type to be meaningful. > > Tested

Re: RFA: PATCH to gimple_canonical_types_compatible_p for middle-end/66214

On Thu, Nov 26, 2015 at 7:32 AM, Jan Hubicka wrote: > Hi, > what aout this? > > Index: tree.c > === > --- tree.c (revision 230924) > +++ tree.c (working copy) > @@ -13424,6 +13424,12 @@

Re: Fix 61441 [3/5] Remove flag_errno_math check for RINT

On Thu, Nov 26, 2015 at 9:31 AM, Saraswati, Sujoy (OSTL) wrote: > Hi, > This patch removes flag_errno_math check for RINT, treating it similar to > nearbyint. > Regards, > Sujoy Ok. Richard. > 2015-11-26 Sujoy Saraswati > > PR

Re: [PATCH 3/4] [ARM] PR63870 Add test cases

On Thu, Nov 26, 2015 at 09:41:15AM +, Charles Baylis wrote: > Hi James, > > Ping. This needs an ack from an AArch64 reviewer/maintainer Fine by me, it will considerably clean up my test results for ARM! Thanks, James

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On Wed, Nov 25, 2015 at 4:54 PM, Michael Matz wrote: > Hi, > > On Wed, 25 Nov 2015, Bernd Schmidt wrote: > >> So here's a very basic version which I think is appropriate for the >> current stage, and can be extended later. Ok if it passes testing? > > When we're improving that

Re: [C++ Patch] PR 68087

On Wed, Nov 25, 2015 at 5:09 PM, Paolo Carlini wrote: > Hi, > > On 11/25/2015 04:59 PM, Markus Trippelsdorf wrote: >>> >>> Index: cp/constexpr.c >>> === >>> --- cp/constexpr.c (revision 230865) >>> +++

Re: [gomp4 06/14] omp-low: copy omp_data_o to shared memory on NVPTX

On Tue, Nov 10, 2015 at 11:39:36AM +0100, Jakub Jelinek wrote: > On Tue, Nov 03, 2015 at 05:25:53PM +0300, Alexander Monakov wrote: > > Here's an alternative patch that does not depend on exposure of > > shared-memory > > address space, and does not try to use pass_late_lower_omp. It's based on

Re: [PATCH][combine] PR rtl-optimization/68381: Only restrict pure simplification in mult-extend subst case, allow other substitutions

On 24/11/15 00:15, Segher Boessenkool wrote: On Thu, Nov 19, 2015 at 03:20:22PM +, Kyrill Tkachov wrote: Hmmm, so the answer to that is a bit further down the validate_replacement: path. It's the code after the big comment: /* See if this is a PARALLEL of two SETs where one SET's

[PATCH] GCC-5 Backport of pr67037

Hi, I have boot-strapped & reg-tested this patch now on arm-linux-gnueabihf with all languages enabled. Is it OK for the gcc-5-branch? Thanks Bernd.gcc: 2015-11-26 Bernd Edlinger Backport from mainline 2015-09-30 Bernd Edlinger

Re: [PATCH] GCC-5 Backport of pr67037

On Thu, 26 Nov 2015, Bernd Edlinger wrote: > > Hi, > > I have boot-strapped & reg-tested this patch now > on arm-linux-gnueabihf with all languages enabled. > > Is it OK for the gcc-5-branch? Ok. Thanks, Richard.

[PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

Hi, This patch fixes redundant bndmov problem by adding bounds registers to ALL_REGS set. This patch was bootstrapped and regtested on x86_64-unknown-linux-gnu. OK for trunk and gcc-5-branch? Thanks, Ilya -- gcc/ 2015-11-26 Vladimir Makarov PR target/68416

Re: [PATCH][GCC][ARM] Disable neon testing for armv7-m

On 20/11/15 16:44, Andre Vieira wrote: Hi Kyrill On 20/11/15 11:51, Kyrill Tkachov wrote: Hi Andre, On 18/11/15 09:44, Andre Vieira wrote: On 17/11/15 10:10, James Greenhalgh wrote: On Mon, Nov 16, 2015 at 01:15:32PM +, Andre Vieira wrote: On 16/11/15 12:07, James Greenhalgh wrote: On

Re: [RFC] Getting LTO incremental linking work

On Wed, 25 Nov 2015, Jan Hubicka wrote: > > > > > > 1) linker plugin is modified to pass -flinker-output to lto wrapper > > > linker-output is either dyn (.so), pie or exec > > > for incremental linking I added .rel for 3) and noltorel for 1) > > > > > > currently it does rel

Re: [PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

Hello! > gcc/ > > 2015-11-26 Vladimir Makarov > > PR target/68416 > * config/i386/i386.h (enum reg_class): Add > bounds registers to ALL_REGS. > > gcc/testsuite/ > > 2015-11-26 Ilya Enkovich > > PR target/68416 > * gcc.target/i386/mpx/pr68416.c:

Re: [PING] Re: [PATCH] c++/67913, 67917 - fix new expression with wrong number of elements

On Thu, Nov 05, 2015 at 12:30:08PM -0700, Martin Sebor wrote: > On 11/02/2015 09:55 PM, Jason Merrill wrote: > >On 10/26/2015 10:06 PM, Martin Sebor wrote: > >>+ if (TREE_CONSTANT (maybe_constant_value (outer_nelts))) > >>+{ > >>+ if (tree_int_cst_lt (max_outer_nelts_tree,

Re: [RFC] Getting LTO incremental linking work

On Thu, 26 Nov 2015, Jan Hubicka wrote: > > > Moreover we do have all infrastructure ready to implement 3). Our tree > > > merging > > > and symbol table handling is fuly incremental and I think made a patch to > > > implement it today. The scheme is easy: > > > > What happens when .S

[PATCH, i386] Use scalar mask for 16-byte and 32-byte vectors when possible

Hi, This patch allows usage of scalar masks for ymm and xmm registers when target supports it. Bootstrapped and regtested on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Ilya -- gcc/ 2015-11-26 Ilya Enkovich * config/i386/i386.c (ix86_get_mask_mode):

Re: [PATCH] New version of libmpx with new memmove wrapper

2015-11-25 18:41 GMT+03:00 Aleksandra Tsvetkova : > gcc/testsuite/ChangeLog > 2015-10-27 Tsvetkova Alexandra > > * gcc.target/i386/mpx/memmove.c: New test for __mpx_wrapper_memmove. > > libmpx/ChangeLog > 2015-10-28 Tsvetkova Alexandra

Re: [PATCH] Fix debug fallout of proposed PR68162 fix

On Wed, 18 Nov 2015, Richard Biener wrote: > > The following patch makes sure we still emit a DW_TAG_typedef for > the element typedef in gcc.dg/debug/dwarf2/pr47939-4.c after a change > to how the C frontend structures the variant chain of arrays. > > It makes dwarf2out _not_ re-build the

Re: Fix PR 67609

On 11/25/2015 06:14 PM, James Greenhalgh wrote: On Tue, Oct 27, 2015 at 01:21:51PM -0700, Richard Henderson wrote: * aarch64 is almost certainly vulnerable, since it deleted its CANNOT_CHANGE_MODE_CLASS implementation in January. I haven't tried to create a test case that fails for it, but

[PATCH][calls.c][4.9/5 backport] PR rtl-optimization/67226: Take into account pretend_args_size when checking stack offsets for sibcall optimisation

Hi all, This is a backport to GCC 4.9 and 5 of the patch at https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03082.html The only difference with the trunk version is that we perform #ifdef checks on STACK_GROWS_DOWNWARD because on these branches we have not moved away from conditional compilation

[PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

Hi all, In this PR we have an IF-THEN-JOIN formation i.e. no ELSE block and we have a situation where the THEN block modifies a register used in emit_b, so emit_b must be emitted before the THEN block. However the bug in the logic that performs these checks ends up to us emitting

Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)

On Wed, Nov 25, 2015 at 03:16:53PM +, Joseph Myers wrote: > > Wonder if we couldn't use some FE specific bit on the SAVE_EXPR to say > > whether c_fully_fold_internal has already processed it or not, and just > > get rid of c_save_expr, in c_fully_fold* recurse into SAVE_EXPRs too, but > >

Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)

On Thu, Nov 26, 2015 at 12:15:48PM +0100, Marek Polacek wrote: > On Wed, Nov 25, 2015 at 03:16:53PM +, Joseph Myers wrote: > > > Wonder if we couldn't use some FE specific bit on the SAVE_EXPR to say > > > whether c_fully_fold_internal has already processed it or not, and just > > > get rid of

Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)

On Thu, 26 Nov 2015, Jakub Jelinek wrote: > On Thu, Nov 26, 2015 at 12:15:48PM +0100, Marek Polacek wrote: > > On Wed, Nov 25, 2015 at 03:16:53PM +, Joseph Myers wrote: > > > > Wonder if we couldn't use some FE specific bit on the SAVE_EXPR to say > > > > whether c_fully_fold_internal has

Re: [PATCH] Improve verification of loop->latch in verify_loop_structure

This caused an ICE compiling value.c from gdb on aarch64-none-linux-gnu; the testcase, after preprocessing on aarch64, ICEs on both aarch64 and x86_64, but is about 1MB - I'm working on reducing that down to something small enough to post... $ ./gcc/xgcc -B ./gcc -O2 -g value.c

Re: [PING] Re: [PATCH] c++/67913, 67917 - fix new expression with wrong number of elements

> Cookies on ARM are 8-bytes [1], but sizeof ((size_t) n) is only 4-bytes, > so this check will fail (We'll ask for 500 bytes, the test here will only > be looking for 496). > > Would it undermine the test for other architectures if I were to swap out > the != for a >= ? I think that is in line

Re: [PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

2015-11-26 13:15 GMT+03:00 Uros Bizjak : > Hello! > >> gcc/ >> >> 2015-11-26 Vladimir Makarov >> >> PR target/68416 >> * config/i386/i386.h (enum reg_class): Add >> bounds registers to ALL_REGS. >> >> gcc/testsuite/ >> >> 2015-11-26 Ilya Enkovich

[PATCH] Fix PR67203

This fixes the g++.dg/tree-ssa/pr61034.C to make the expected result dependent on PUSH_ARGS_REVERSED (via an explicit list of targets). With swapping the final cd_dce and dse passes I get all targets to produce zero 'free' calls in .optimized but that doesn't sound appropriate at this stage.

[PATCH] -Wshift-overflow: Warn for shifting sign bit out of a negative number

maybe_warn_shift_overflow is checking for patterns such as (1 << 31) and not warning for them. However, if the shifted value is negative, a shift by a non-zero amount will always shift *out* of the sign bit rather than into it. Thus it should be warned about, even if the value only requires one

Re: [PATCH] Improve verification of loop->latch in verify_loop_structure

Here's a reduced testcase (reduced to the point of generating lots of warnings, I'm compiling with -O2 -w, on x86_64): struct __jmp_buf_tag { }; typedef struct __jmp_buf_tag sigjmp_buf[1]; extern struct cmd_list_element *showlist; struct internalvar { struct internalvar *next; }; static

[PATCH] Add PR rtl-optimization/68249 and PR rtl-optimization/68321 testcases

Hi! These PRs are dups of PR68194 that has been fixed recently. I've added the testcases for them to the trunk and 5 branch. 2015-11-26 Jakub Jelinek PR rtl-optimization/68249 PR rtl-optimization/68321 * gcc.c-torture/execute/pr68249.c: New test.

Fix PR c++/68527

This is a tree checking failure on invalid C++ code with -fdump-ada-spec. I guess that we could simply bail out if there are errors in the code, but we already have guards for error_mark_node so the patch adds a couple more. Tested on x86_64-suse-linux, applied on the mainline as obvious.

Re: [PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

On Thu, Nov 26, 2015 at 12:46 PM, Ilya Enkovich wrote: > 2015-11-26 13:15 GMT+03:00 Uros Bizjak : >>> 2015-11-26 Vladimir Makarov >>> >>> PR target/68416 >>> * config/i386/i386.h (enum reg_class): Add >>> bounds registers to

Re: [PATCH] Improve verification of loop->latch in verify_loop_structure

On Thu, 26 Nov 2015, Alan Lawrence wrote: > This caused an ICE compiling value.c from gdb on > aarch64-none-linux-gnu; the testcase, after preprocessing on aarch64, > ICEs on both aarch64 and x86_64, but is about 1MB - I'm working on > reducing that down to something small enough to post... > >

[patch] Copy-edit the Option Summary in invoke.texi

At https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html we document -Waggressive-loop-optimizations but you can't find that option at https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html because we document -Wno-aggressive-loop-optimizations instead. Similarly, you can't find

Re: [PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

On Thu, 26 Nov 2015, Uros Bizjak wrote: > On Thu, Nov 26, 2015 at 12:46 PM, Ilya Enkovich > wrote: > > 2015-11-26 13:15 GMT+03:00 Uros Bizjak : > > >>> 2015-11-26 Vladimir Makarov > >>> > >>> PR target/68416 > >>> *

Re: [PATCH, PR target/68416, i386, MPX] Add bounds registers to ALL_REGS set

2015-11-26 15:18 GMT+03:00 Richard Biener : > On Thu, 26 Nov 2015, Uros Bizjak wrote: > >> On Thu, Nov 26, 2015 at 12:46 PM, Ilya Enkovich >> wrote: >> > 2015-11-26 13:15 GMT+03:00 Uros Bizjak : >> >> >>> 2015-11-26 Vladimir Makarov

Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)

On Thu, 26 Nov 2015, Marek Polacek wrote: > I had a go at this, but I'm now skeptical about removing c_save_expr. > save_expr calls fold (), so we need to ensure that we don't pass any > C_MAYBE_CONST_EXPRs into it, meaning that we'd need to call c_fully_fold > before > save_expr anyway... > >

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

On 11/25/2015 07:35 PM, Jason Merrill wrote: Actually, even though my patches introduce DWARF procedures for only one case (size functions from stor-layout.c), they don’t necessarily come from code generation (GENERIC): they are just a way to factorize common DWARF operations. Thinking more

Re: [PATCH 01/15] Selftest framework (unittests v4)

On 11/25/2015 11:47 PM, David Malcolm wrote: FWIW, the reason I special-cased the linked list was to avoid any dynamic memory allocation: the ctors run before main, so I wanted to keep them as simple as possible. Is there any particular reason for this? C++ doesn't disallow memory allocation

Re: [PATCH][combine] PR rtl-optimization/68381: Only restrict pure simplification in mult-extend subst case, allow other substitutions

On Thu, Nov 26, 2015 at 09:50:50AM +, Kyrill Tkachov wrote: > As I mentioned on IRC, this patch improves codegen on aarch64 as well. > I've re-checked SPEC2006 and it seems to improve codegen around > multiply-extend-accumulate > instructions. For example the sequence: > movw4, 64 >

Re: [PATCH][combine] PR rtl-optimization/68381: Only restrict pure simplification in mult-extend subst case, allow other substitutions

On Thu, Nov 19, 2015 at 10:26:25AM +, Kyrill Tkachov wrote: > Ok for trunk? > > Thanks, > Kyrill > > 2015-11-19 Kyrylo Tkachov > > PR rtl-optimization/68381 > * combine.c (subst): Do not return clobber of zero in widening mult > case. Just return x

[PATCH] Fix genmatch SAVE_TEMPS usage for multi-uses

This fixes the issue that genmatch wraps captures in SAVE_TEMPS only for correctness reasons right now (for TREE_SIDE_EFFECTS captures) but not to avoid duplicating expensive computations. The following fixes that. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk, testing

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index af7a3b9..3e3dc8d 100644 --- a/gcc/ifcvt.c +++ b/gcc/ifcvt.c @@ -2220,7 +2220,7 @@ noce_try_cmove_arith (struct noce_if_info *if_info) } } -if (emit_a && modified_in_a) +if (emit_a

[PATCH] Fix PR68554

Committed. Richard. 2015-11-26 Richard Biener PR testsuite/68554 * gcc.dg/vect/bb-slp-subgroups-2.c: Require vect_perm. Index: gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-2.c === ---

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 26/11/15 13:40, Bernd Schmidt wrote: On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index af7a3b9..3e3dc8d 100644 --- a/gcc/ifcvt.c +++ b/gcc/ifcvt.c @@ -2220,7 +2220,7 @@ noce_try_cmove_arith (struct noce_if_info *if_info) } } -if

[PATCH] Fix PR68555

Committed. Richard. 2015-11-26 Richard Biener PR testsuite/68555 * gcc.dg/vect/bb-slp-10.c: Adjust pattern, use target selector and not XFAIL. Index: gcc/testsuite/gcc.dg/vect/bb-slp-10.c

Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

On 6 November 2015 at 16:59, Jakub Jelinek wrote: > > In any case, to manually reproduce, compile > gnatmake -g -gnatws macrosub.adb > with GCC 5.1.1 (before the ARM changes) and then try to run that process > against > GCC 5.2.1 (after the ARM changes) libgnat-5.so, which is

[PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches='

Move the `-mcompact-branches=' option out of the middle of a block of floating-point options. The option is not related to FP in any way. Place it immediately below other branch instruction selection options. gcc/ * doc/invoke.texi (Option Summary) : Reorder

[PTX] simplify call emission

I've committed this patch to simplify some more call emission machinery. write_func_decl_from_insn was doing more work than necessary. 1) it doesn't need to examine the callee to figure out whether this is an indirect call or not. It's callers have already done this, and can pass in the

Re: [PR68432 00/26] Handle size/speed choices for internal functions

On 11/25/2015 01:20 PM, Richard Sandiford wrote: This series fixes PR 68432, a regression caused by my internal-functions- for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* condition but conditionally FAIL if we're optimising for size: if (SSE_FLOAT_MODE_P (mode) &&

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

Thank you Jason! On 11/25/2015 09:35 PM, Eric Botcazou wrote: We try to declare variables only at the first use point now I think. Fixed, thanks! + /* Debugging information needs to compute the frame base address of the +nestee frame out of the static chain from the nested

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 02:52 PM, Kyrill Tkachov wrote: On 26/11/15 13:40, Bernd Schmidt wrote: On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: modified_in_b = emit_b != NULL_RTX && modified_in_p (orig_a, emit_b); Can this ever be true? We arrange for emit_b to set a new pseudo, don't we? Are we

Re: [PR68432 20/22] Record attributes for define_expand

On 11/25/2015 05:08 PM, Richard Sandiford wrote: Also, using a string like that rather than some kind of identifier or a define_icode_attr maybe isn't the best approach? By "some kind of identifier" do you just mean replacing "code,alternative" with a string that doesn't have a comma? Yeah.

[PATCH RFC 1/2] MIPS/GCC: Factor out LINK_SPEC

Factor out common linker specs to LINK_SPEC, to be included from individual SUBTARGET_LINK_SPEC definitions, along the lines of SUBTARGET_ASM_SPEC, SUBTARGET_CC1_SPEC, SUBTARGET_CPP_SPEC, etc. This essentially revives the use of the LINK_SPEC definition from mips.h which by now has become

[PATCH RFC 0/2] GCC: MIPS IEEE Std 754 NaN interlinking support

Hi, This implements the GCC interface for IEEE Std 754 NaN interlinking, following the recommendations set out in the "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" document available here: . Two patches comprise

[PATCH RFC 2/2] MIPS/GCC: IEEE Std 754 NaN interlinking support

Implement the GCC interface for IEEE Std 754 NaN interlinking, following "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" and the recommendations set out there as follows: * implement driver and compiler command-line

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 26/11/15 14:23, Bernd Schmidt wrote: On 11/26/2015 02:52 PM, Kyrill Tkachov wrote: On 26/11/15 13:40, Bernd Schmidt wrote: On 11/26/2015 12:12 PM, Kyrill Tkachov wrote: modified_in_b = emit_b != NULL_RTX && modified_in_p (orig_a, emit_b); Can this ever be true? We arrange for

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in IF-THEN-JOIN case

On 11/26/2015 03:35 PM, Kyrill Tkachov wrote: Would it be ok if I did that as a separate follow-up patch? We don't have a testcase where this actually causes trouble and I'd like to keep the fix for this PR as self-contained as possible. Sure. Bernd

Re: [PATCH] Improve verification of loop->latch in verify_loop_structure

On 26/11/15 13:15, Richard Biener wrote: On Thu, 26 Nov 2015, Alan Lawrence wrote: This caused an ICE compiling value.c from gdb on aarch64-none-linux-gnu; the testcase, after preprocessing on aarch64, ICEs on both aarch64 and x86_64, but is about 1MB - I'm working on reducing that down to

Improving the cxx0x_warning.h diagnostic

We have lots of headers that do this: #if __cplusplus < 201103L # include #else and that file has a #error (not #warning as the name would suggest). Unfortunately a #error does not stop compilation, so when users try to compile C++11 source code (which includes standard headers) and they

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

> Here’s the updated patch. Regtested again on x86_64-linux. Thanks, it looks good as far as I'm concerned (modulo the missing "in order" before "not to shift all other offsets" in a comment). -- Eric Botcazou

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

On 11/26/2015 03:50 PM, Eric Botcazou wrote: Here’s the updated patch. Regtested again on x86_64-linux. Thanks, it looks good as far as I'm concerned (modulo the missing "in order" before "not to shift all other offsets" in a comment). Fixed and pushed. Thank you again for reviewing! --

Re: [PR68432 00/26] Handle size/speed choices for internal functions

Bernd Schmidt writes: > On 11/25/2015 01:20 PM, Richard Sandiford wrote: >> This series fixes PR 68432, a regression caused by my internal-functions- >> for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* >> condition but conditionally FAIL if we're

Re: [PATCH] libstdc++: Fix libstdc++/67440: pretty-printing of a const set fails

On 25/11/15 19:55 +, Jonathan Wakely wrote: On 25 November 2015 at 17:29, Alan Lawrence wrote: On 16/11/15 21:04, Doug Evans wrote: Hi. Apologies for the delay. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 Tested with current trunk. 2015-11-16 Doug Evans

[PATCH 1/7][ARM] Add support for ARMv8.1.

Hello, ARMv8.1 includes an extension to ARM which adds two Adv.SIMD instructions, vqrdmlah and vqrdmlsh. This patch set adds support for ARMv8.1 and for the new instructions, enabling the architecture with --march=armv8.1-a. The new instructions are enabled when both ARMv8.1 and a suitable fpu

RE: [PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches='

> -Original Message- > From: Maciej W. Rozycki [mailto:ma...@imgtec.com] > Sent: Thursday, November 26, 2015 9:01 AM > To: gcc-patches@gcc.gnu.org > Cc: Moore, Catherine; Matthew Fortune > Subject: [PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches=' > > Move the `-mcompact-branches='

[PATCH 2/7][ARM] Multilib support for ARMv8.1.

This patch sets up multilib support for ARMv8.1, treating it as a synonym for ARMv8. Since ARMv8.1 integer, FP or SIMD instructions are only generated for the new, instruction-specific instrinsics, mapping to ARMv8 rather than adding a new multilib variant is sufficient. Tested the series for

[PATCH 3/7][ARM] Add patterns for new instructions

Hello, This patch adds patterns for the instructions, vqrdmlah and vqrdmlsh, introduced in the ARMv8.1 architecture. The instructions are made available when -march=armv8.1-a is enabled with suitable fpu settings, such as -mfpu=neon-fp-armv8 -mfloat-abi=hard. Tested the series for arm-none-eabi

[PATCH 4/7][ARM] Add ACLE feature macro for ARMv8.1 instructions.

Hello, This patch adds the feature macro __ARM_FEATURE_QRDMX to indicate the presence of the ARMv8.1 instructions vqrdmlah and vqrdmlsh. It is defined when the instructions are available, as it is when -march=armv8.1-a is enabled with suitable fpu options. Tested the series for arm-none-eabi

[PATCH 5/7][Testsuite] Support ARMv8.1 ARM tests.

Hello, This patch adds ARMv8.1 support to GCC Dejagnu, to allow ARM tests to specify targest and to set up command line options. It builds on the ARMv8.1 target support added for AArch64 tests, partly reworking that support to take into account the different configurations that tests may be run

Re: [wwwdocs] Update C++ conformance status

On 21/11/15 16:54 +0100, Gerald Pfeifer wrote: On Sat, 21 Nov 2015, Jonathan Wakely wrote: I forgot to respond to this, and never committed the patch, sorry. I've committed the changes to htdocs/projects/cxx0x.html now, but not the htdocs/bugs/index.html change. I wasn't opposed to the

[PATCH 6/7][ARM] Add ACLE intrinsics vqrdmlah and vqrdmlsh

Hello, This patch adds the ACLE intrinsics for the instructions introduced in ARMv8.1. It adds the vqrmdlah and vqrdmlsh forms of the instrinsics to the arm_neon.h header, together with the ARM builtins used to implement them. The intrinsics are available when -march=armv8.1-a is enabled

[PATCH 7/7][ARM] Add ACLE intrinsics vqrdmlah_lane and vqrdmlsh_lane

Hello, This patch adds the ACLE intrinsics for the instructions introduced in ARMv8.1. It adds the vqrmdlah_lane and vqrdmlsh_lane forms of the instrinsics to the arm_neon.h header, together with the ARM builtins used to implement them. The intrinsics are available when -march=armv8.1-a is

Re: [PR68432 00/26] Handle size/speed choices for internal functions

On 11/26/2015 04:13 PM, Richard Sandiford wrote: That would mean that the validity of a gimple call would depend on both the target predicates and whether the block containing the statement is optimised for size or speed. So whenever we want to test whether a gimple call is valid, we'd need to

  1   2   >