[PATCH] IRA: Don't create new regs for debug insns (PR80429)

In split_live_ranges_for_shrink_wrap IRA also splits regs that are only used in debug insns, leading to -fcompare-debug failures. Bootstrapped and tested on powerpc64-linux {-m32,-m64}. This happens on at least GCC 5, so not a regression; but it is trivial and obvious, is it okay for trunk anyway

Re: [PATCH] IRA: Don't create new regs for debug insns (PR80429)

On Tue, Apr 18, 2017 at 09:30:19AM +, Segher Boessenkool wrote: > In split_live_ranges_for_shrink_wrap IRA also splits regs that are > only used in debug insns, leading to -fcompare-debug failures. > > Bootstrapped and tested on powerpc64-linux {-m32,-m64}. This happens > on at least GCC 5, s

Re: [PATCH], Fix PR/target 80099 (internal error with -mno-upper-regs-sf)

On Sat, Apr 15, 2017 at 01:43:18AM -0400, Michael Meissner wrote: > You are right, and my patch was too complicated. All I needed to do was > remove > the upper register checks. In looking at it, since the insn before being > split > has both register and memory versions, if the register alloca

[PATCH GCC8][01/33]Handle TRUNCATE between tieable modes in rtx_cost

Hi, This patch series rewrites parts of IVOPTs. The change consists of below described parts: A) New cost computation model. Currently, there are big amount code trying to understand tree expression and estimate its computation cost. The model is designed long ago for generic tree

[PATCH GCC8][02/33]Remove code handling pseudo candidate

Hi, We don't have pseudo candidate nowadays, so remove any related code. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (get_computation_cost_at): Remove pseudo iv_cand code. (determine_group_iv_cost_cond, determine_iv_cost): Ditto. (iv_ca

[PATCH GCC8][04/33]Single interface finding invariant variables

Hi, This patch refactors interface finding invariant variables. Now customers only need to call find_inv_vars, rather than set global variable fd_ivopts_data then call walk_tree. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (struct walk_tree_data): New.

[PATCH GCC8][03/33]Refactor invariant variable/expression handling

Hi, This patch refactors how invariant variable/expressions are handled. Now they are recorded in the same kind data structure and handled similarly, which makes code easier to understand. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (struct cost_pair): Renam

[PATCH GCC8][05/33]Count invariant and candidate separately

Hi, Simple refactor counting invariant (both variables and expressions) and induction variables separately. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (struct iv_ca): Rename n_regs to n_invs. (ivopts_global_cost_for_size): Rename parameter and update u

[PATCH GCC8][06/33]Simple refactor of function rewrite_use_address

Hi, Simple refactor for function rewrite_use_address. Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (rewrite_use_address): Simple refactor.From 1eea1956061dedd62bcbec119d9febb8a18d2a0d Mon Sep 17 00:00:00 2001 From: Bin Cheng Date: Tue, 28 Feb 2017 14:54:32 + Subject:

[PATCH GCC8][07/33]Offset validity check in address expression

Hi, For now, we check validity of offset by computing the maximum offset then checking if offset is smaller than the max offset. This is inaccurate, for example, some targets may require offset to be aligned by power of 2. This patch introduces new interface checking validity of offset. It al

[PATCH GCC8][08/33]Clean get_computation_*interfaces

Hi, This patch cleans get_computation* interfaces. Specifically, it removes get_computation and get_computation_cost_at. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (get_computation_at): Reorder parameters. (get_computation): Delete. (get_compu

[PATCH GCC8][09/33]Compute separate aff_trees for invariant and induction parts

Hi, This patch computes and returns separate aff_trees for invariant expression and induction expression, so that invariant and induction parts can be handled separately in both cost computation and code generation. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (

[PATCH GCC8][10/33]Clean get_scaled_computation_cost_at and the dump info

Hi, This patch simplifies function get_scaled_computation_cost_at and the dump information. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (get_scaled_computation_cost_at): Delete parameter cand. Update dump information. (get_computation_cost): U

[PATCH GCC8][12/33]Expose interfaces of tree-ssa-address.c

Hi, This patch exposes several interfaces in tree-ssa-address.c so that they can be used in cost computation for address iv_use. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-address.c (struct mem_address): Move to header file. (valid_mem_ref_p, move_fixed_address_to_

[PATCH GCC8][11/33]New interfaces for tree affine

Hi, This patch adds three simple interfaces for tree affine which will be used in cost computation later. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-affine.h (aff_combination_type): New interface. (aff_combination_const_p, aff_combination_simple_p): New interfaces.From

[PATCH GCC8][14/33]Handle more cheap operations in force_expr_to_var_cost

Hi, This patch handles more cheap cases in function force_expr_to_var_cost, specifically, TRUNC_DIV_EXPR, BIT_AND_EXPR, BIT_IOR_EXPR, RSHIFT_EXPR and BIT_NOT_EXPR. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Handle more operat

[PATCH GCC8][13/33]Rewrite cost computation of ivopts

Hi, This is the major part of this patch series. It rewrites cost computation of ivopts using tree affine. Apart from description given by cover message: A) New computation cost model. Currently, there are big amount code trying to understand tree expression and estimate its computation

[PATCH GCC8][15/33]Simplify function autoinc_possible_for_pair

Hi, This patch simplifies function autoinc_possible_for_pair by deleting unnecessary local variables. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (autoinc_possible_for_pair): Simplify.From 09ea8cf6f542ab270ba9994f8491b926fc78237d Mon Sep 17 00:00:00 2001 From:

[PATCH GCC8][16/33]Move multiplier_allowed_in_address_p to tree-ssa-address

Hi, Now function multiplier_allowed_in_address_p is no longer referred in ivopts, so move to the only file using it and make it static. Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (multiplier_allowed_in_address_p): Move from ... * tree-ssa-address.c (multi

[PATCH GCC8][18/33]Relate compare iv_use with all candidates

Hi, For compare type iv_use, we want to relate it with all candidates in order to achieve smaller candidate set. Generally this doesn't hurt compilation time because compare iv_use is already related with most candidates and the number of compare iv_uses is also small. Is it OK? Thanks, bin 2017-

[PATCH GCC8][17/33]Treat complex cand step as invriant expression

Hi, We generally need to compute cand step in loop preheader and use it in loop body. Unless it's an SSA_NAME of constant integer, an invariant expression is needed. Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (struct iv_cand): New field inv_exprs. (dump_cand):

[PATCH GCC8][19/33]Rewrite nonlinear iv_use by re-associating invariant and induction parts separately

Hi, This patch rewrites nonlinear iv_use by re-associating invariant part and induction part separately so that invariant expressions are exposed to later lim pass. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Re-associate no

[PATCH GCC8][20/33]Support compare iv_use which is compared against arbitrary variable

Hi, Currently we only support compare iv_use if the other side of comparison is loop invariant. Such compare iv_use can never be eliminated, but it still can be expressed. This patch supports the case that the other side of comparison is an arbitrary non-iv variables. Is it OK? Thanks, bin 20

[PATCH GCC8][21/33]Support compare iv_use which both sides of comparison are IVs

Hi, This patch supports compare iv_use for comparison whose both sides are IVs. With this patch, optimal code is generated for PR53090. Is it OK? Thanks, bin 2017-04-11  Bin Cheng      PR tree-optimization/53090     * tree-ssa-loop-ivopts.c (enum comp_iv_rewrite): New enum value    

[PATCH GCC8][22/33]Generate TMR in new reassociation order

Hi, This patch generates TMR for ivopts in new re-association order. General idea is, by querying target's addressing mode, we put as much address computation as possible in memory reference. For computation that has to be done outside of memory reference, we re-associate the address expressio

[PATCH 24/33]New parameter bound on number of selected candidates

Hi, IVOPTs still have difficulty for outer loop (especially for large loop nest), and tend to select too many candidates. It's generally bad because of unavoidable register spilling. In this case, we probably want to compute iv_uses with small number of bivs. Though this results in more computa

[PATCH GCC8][23/33]Simple comment adjustment

Hi, This is simple comment adjustment. Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (allow_ip_end_pos_p): Refine comments. (get_shiftadd_cost): Ditto.From 9f2ca115ef2e376a472d591864a2d7a7dd9daacf Mon Sep 17 00:00:00 2001 From: Bin Cheng Date: Wed, 1 Mar 2017 17:36

[PATCH GCC8][25/33]New loop constraint flags

Hi, This patch adds new loop constraint flags marking prologue, epilogue and versioned loops generated by vectorizer, unroller and versioning. These flags will be used in IVOPTs in order to differentiate possible hot innermost loop from others. I also plan to use them to avoid unnecessary cunr

[PATCH GCC8][26/33]Record newly used inv_vars during cost computation

Hi, At the moment, inv_vars are recognized during finding iv_uses. It's also possible that inv_vars are used when expressing iv_use with specific cand. Unfortunately, such inv_vars are neither recognized nor considered in reg pressure estimation. This patch modifies find_inv_vars_cb so that such

[PATCH GCC8][27/33]Extend candidate set if new_cp has cheaper dependence

Hi, Currently we only allow iv_ca extension if new_cp has cheaper cost and less deps than old_cp. This is inaccurate because it's possible the overall deps is reduced even new_cp has more deps than old_cp. This happens in case that new_cp's deps are already in iv_ca. This patch allows more iv_

[PATCH GCC8][28/33]Don't count non-interger PHIs for register pressure

Hi, Given only integer variables are meaningful for register pressure estimation in IVOPTs, this patch skips non-integer type PHIs when counting register pressure. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-ssa-loop-ivopts.c (determine_set_costs): Skip non-interger when

[PATCH GCC8][29/33]New register pressure estimation

Hi, Currently IVOPTs shares the same register pressure computation with RTL loop invariant pass, which doesn't work very well. This patch introduces specific interface for IVOPTs. The general idea is described in the cover message as below: C) Current implementation shares the same register pr

[PATCH GCC8][30/33]Fold more type conversion into binary arithmetic operations

Hi, Simplification of (T1)(X *+- CST) is already implemented in aff_combination_expand, this patch moves it to tree_to_aff_combination. It also supports unsigned types if range information allows the transformation, as well as special case (T1)(X + X). Is it OK? Thanks, bin 2017-04-11 Bin Chen

[PATCH GCC8][31/33]Set range information for niter bound of vectorized loop

Hi, Based on vect_peeling algorithm, we know for sure that vectorized loop must iterates at least once. This patch sets range information for niter bounds of vectorized loop. This helps niter analysis, so iv elimination too. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-vect-loo

[PATCH GCC8][32/33]Save niter check for vect peeling if loop versioning is required

Hi, When loop versioning is required in vectorization, we can merge niter check for vect peeling with the check for loop versioning, thus save one check/branch for vectorized loop. Is it OK? Thanks, bin 2017-04-11 Bin Cheng * tree-vect-loop-manip.c (vect_do_peeling): Don't skip vecto

[PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

Hi, This is the same patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02000.html, after rebase against this patch series. This patch was blocked because without this patch series, it could generate worse code on targets with limited addressing mode support, like AArch64. There was

[PATCH] Fix incorrect results from std::boyer_moore_searcher

Nico noticed the return value of std::boyer_moore_searcher has the wrong position for the end of the match. Fixed by this patch, which also does some minor cleanup (like removing redundant std:: quals that were copied from the std::experimental::boyer_moore_searcher version). * include/st

Re: [RFA][PATCH] Fix mips16 codegen issue in a better way

Jeff Law writes: > [RFA is for the regcprop bits, reverting the mips.md hack seems like a > no-brainer with the regcprop change. ] > > > Per the recent discussion between Richard S. and myself, this is a > better fix for the mips16 codegen issue where it's creating invalid lwu > insns. > > As R

Re: [PATCH GCC8][04/33]Single interface finding invariant variables

On Tue, Apr 18, 2017 at 10:39:30AM +, Bin Cheng wrote: > -find_depends (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data) > +find_inv_vars_cb (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data) > { > - bitmap *inv_vars = (bitmap *) data; > + struct walk_tree_data *wdata = (struct walk_tre

Re: [PATCH GCC8][04/33]Single interface finding invariant variables

On Tue, Apr 18, 2017 at 1:20 PM, Trevor Saunders wrote: > On Tue, Apr 18, 2017 at 10:39:30AM +, Bin Cheng wrote: >> -find_depends (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data) >> +find_inv_vars_cb (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data) >> { >> - bitmap *inv_vars = (bitma

[patch,avr,committed, trunk + v6] Fix PR79453

Applied the patchlet below to fix a translation hiccup in the AVR backend. Johann PR target/79453 * config/avr/avr.c (intl.h): Include it. (avr_pgm_check_var_decl) [reason]: Wrap diagnostic snippets into _(). Index: config/avr/avr.c =

Patch ping^2

I'd like to ping following patch: PR debug/80263 http://gcc.gnu.org/ml/gcc-patches/2017-04/msg4.html avoid emitting sizetype artificial name into debug info Thanks Jakub

Re: [PATCH GCC8][04/33]Single interface finding invariant variables

On Tue, Apr 18, 2017 at 01:58:43PM +0100, Bin.Cheng wrote: > On Tue, Apr 18, 2017 at 1:20 PM, Trevor Saunders > wrote: > > On Tue, Apr 18, 2017 at 10:39:30AM +, Bin Cheng wrote: > >> -find_depends (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data) > >> +find_inv_vars_cb (tree *expr_p, int *

Re: [PATCH v2] Generate reproducible output independently of the build-path

Ximin Luo: > [..] > > I will soon test this patch backported to Debian GCC-6 on > tests.reproducible-builds.org and will have results in a few days or weeks. > Some preliminary tests earlier gave good results (about +40 packages > reproducible over ~2 days) but we had to abort due to some missched

Re: [RFA][PATCH] Fix mips16 codegen issue in a better way

On 04/18/2017 05:16 AM, Richard Sandiford wrote: Jeff Law writes: [RFA is for the regcprop bits, reverting the mips.md hack seems like a no-brainer with the regcprop change. ] Per the recent discussion between Richard S. and myself, this is a better fix for the mips16 codegen issue where it's

[committed] Fix -fsanitize-coverage=trace-pc -fcompare-debug bug (PR sanitizer/80444)

Hi! As the pass doesn't want to insert into empty bbs and also copies locus from the stmt it is inserted before, we have to make sure we insert it before non-debug stmt (and as empty bb also consider blocks with just labels and debug stmts). Bootstrapped/regtested on x86_64-linux and i686-linux,

[PATCH] Fix VRP intersect_ranges for 1-bit precision signed types (PR tree-optimization/80443)

Hi! As can be seen on the testcase, intersect_ranges in some cases attempts to add or subtract 1 from one of the bounds. That is fine except for 1-bit signed type, where 1 is not a value in the range of the type, so already build_int_cst yields (OVF) constant. The following patch fixes it by spe

[PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

Hi! As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on ARRAY_TYPEs to denote types that need the special C++ alias handling. The problem is how is that created, we just use build_array_type and set TYPE_TYPELESS_STORAGE on the result, but build_array_type uses type caching, so we mig

[PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

Hello all This patch adds the support for BIC (vector, immediate) and ORR (vector, immediate) SIMD patterns to the AArch64 backend. One of the examples of this is : (with -O2 -ftree-vectorize) void bic_s (short *a) { for (int i = 0; i < 1024; i++) a[i] &= ~(0xff); } which now produces :

Re: Patch ping^2

On 04/18/2017 07:55 AM, Jakub Jelinek wrote: I'd like to ping following patch: PR debug/80263 http://gcc.gnu.org/ml/gcc-patches/2017-04/msg4.html avoid emitting sizetype artificial name into debug info OK. jeff

Re: [RFA][PATCH][P2][PR middle-end/80422] Fix crossjumping ICE

On Mon, Apr 17, 2017 at 10:20:28AM -0600, Jeff Law wrote: > PR middle-end/80422 > * cfgcleanup.c (try_crossjump_to_edge): Verify SRC1 and SRC2 have > predecessors after walking up the insn chain. > > > PR middle-end/80422 > * gcc.c-torture/compile/pr80422.c: New test

Re: Fix ICE with -fauto-profile when walking vdefs

On Mon, Apr 3, 2017 at 5:34 AM, Richard Biener wrote: > On Fri, 31 Mar 2017, Sebastian Pop wrote: > >> On Fri, Mar 31, 2017 at 12:06 PM, Richard Biener wrote: > Does the following fix it? > > Index: gcc/auto-profile.c > === > --- gcc

Re: [PATCH] Fix fixincludes for canadian cross builds

On 04/14/17 12:29, Bernd Edlinger wrote: > Hi RMs: > > I am sorry that this happened so close to the imminent gcc-7 release > date. > > To my best knowledge it would be fine to apply this update patch on the > trunk: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00649.html > > But if you decide oth

Re: [PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 04/17/2017 09:54 PM, Sandra Loosemore wrote: @item -falign-functions @itemx -falign-functions=@var{n} +@itemx -falign-functions=@var{n},@var{m} +@itemx -falign-functions=@var{n},@var{m},@var{n2} +@itemx -falign-functions=@var{n},@var{m},@var{n2},@var{m2} @opindex falign-functions Align

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2017-04-18 Denys Vlasenko * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-common.c

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

This change drops forced alignment to 8 if requested alignment is higher than 8: before the patch, -falign-functions=9 was generating .p2align 4,,8 .p2align 3 which means: "align to 16 if the skip is 8 bytes or less; else align to 8". After this change, ".p2align 3" is not emitted

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 8

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" An extended explanation is in commit message of patch 3. The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1;

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

falign-functions=N is too simplistic. Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte alignment of functions runs fastest (he tried many other possibilites): this way, after a call CPU can fetch a lot of insns in the first cacheline fill. However, developers are less tha

Re: PR80357: Negative register pressure

On 04/14/2017 04:37 AM, Richard Sandiford wrote: In the PR testcase, there were two instructions that had a large number of insn_reg_use records for the same register. model_recompute was instead expecting the records to be unique and so decremented the register pressure for each one. We then en

Re: [PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 04/18/2017 12:30 PM, Denys Vlasenko wrote: 2017-04-18 Denys Vlasenko * doc/invoke.texi: Update option documentation. [snip] The documentation part of this version is OK. -Sandra

Re: [PATCH] Fix VRP intersect_ranges for 1-bit precision signed types (PR tree-optimization/80443)

On April 18, 2017 5:06:48 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >As can be seen on the testcase, intersect_ranges in some cases attempts >to add or subtract 1 from one of the bounds. That is fine except for >1-bit signed type, where 1 is not a value in the range of the type, >so already build

Re: [PATCH] PR80101: Fix ICE in store_data_bypass_p

[Sorry for the long delay] > Why is it nonsense? The predicate gives the answer to the question > "given these insns A and B, does A feed data that B stores in memory". > That is a perfectly valid question to ask of any two insns. I disagree, for example it's nonsensical to send it a blockage in

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

I was attempting to build a spec 2006 run on a little endian power8 PowerPC system with all of your patches installed. I had problems with the dealII benchmark: --> ./xgcc -B./ -O2 -S function_lib.ii -ftree-vectorize function_lib.cc: In member function ‘Tensor<2, dim> Functions::CosineFunction::

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

By the way, if anybody else wanted to try the patches, but did not want to apply all 33 patches, I cloned the trunk and applied the patches to the following branch: svn+ssh://gcc.gnu.org/svn/gcc/branches/ibm/ivopts -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245

Re: [PATCH] libiberty: Don't update and remove did_subs field from demangler structs.

Hi, On Sat, Dec 03, 2016 at 10:54:58PM +0100, Mark Wielaard wrote: > The d_info field did_subs was used for estimating the string output > size. It was no longer used when the malloc-less callback interface > was introduced in 2007 (svn r121305). But the field was still updated. > When backtrackin

Re: [PATCH] libiberty: Don't update and remove did_subs field from demangler structs.

On Tue, Apr 18, 2017 at 1:56 PM, Mark Wielaard wrote: > > On Sat, Dec 03, 2016 at 10:54:58PM +0100, Mark Wielaard wrote: >> The d_info field did_subs was used for estimating the string output >> size. It was no longer used when the malloc-less callback interface >> was introduced in 2007 (svn r121

[PATCH] libiberty: Always return NULL if d_add_substitution fails.

d_add_substitution can fail for various reasons, like when the subs array is full. If d_add_substitution fails d_substitution should return NULL early and not try to continue. Every other call of d_add_substitution is handled in the same way. libiberty/ChangeLog: * cp-demangle.c (d_substi

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

I did a bootstrap and make check-{gcc,c++,fortran,lto} comparing the results to the baseline (subversion id 246975). There were 2 differences: The baseline failed on gcc.dg/sms-4.c but succeeded on gcc.dg/sms-1.c. Here are the sms-[14] lines from the baseline: Executing on host: /home/meissner/

Re: [PATCH] libiberty: Always return NULL if d_add_substitution fails.

On Tue, Apr 18, 2017 at 2:21 PM, Mark Wielaard wrote: > d_add_substitution can fail for various reasons, like when the subs array > is full. If d_add_substitution fails d_substitution should return NULL > early and not try to continue. Every other call of d_add_substitution > is handled in the sam

[PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.

The fix for PR demangler/70909 and 67264 (endless demangler recursion) catches when a demangle_component is printed in a cycle. But that doesn't protect the call stack blowing up from non-cyclic nested types printed recursively through d_print_comp. This can happen by a (very) long mangled string t

[PATCH] Fix PR80457

Hi, While investigating a performance issue, I happened to notice that vectorized COND_EXPRs were not contributing to the vectorizer cost model. This patch addresses that. Bootstrapped and tested on powerpc64le-unknown-linux-gnu. Is this ok for trunk, or should it wait for GCC 8? Thanks, Bill

Re: [PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.

On Tue, Apr 18, 2017 at 3:23 PM, Mark Wielaard wrote: > The fix for PR demangler/70909 and 67264 (endless demangler recursion) > catches when a demangle_component is printed in a cycle. But that doesn't > protect the call stack blowing up from non-cyclic nested types printed > recursively through

Re: [PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.

On Tue, Apr 18, 2017 at 03:40:05PM -0700, Ian Lance Taylor wrote: > On Tue, Apr 18, 2017 at 3:23 PM, Mark Wielaard wrote: > > The fix for PR demangler/70909 and 67264 (endless demangler recursion) > > catches when a demangle_component is printed in a cycle. But that doesn't > > protect the call st

Re: [PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.

On Tue, Apr 18, 2017 at 4:03 PM, Mark Wielaard wrote: > On Tue, Apr 18, 2017 at 03:40:05PM -0700, Ian Lance Taylor wrote: >> On Tue, Apr 18, 2017 at 3:23 PM, Mark Wielaard wrote: >> > The fix for PR demangler/70909 and 67264 (endless demangler recursion) >> > catches when a demangle_component is

[PATCH][PR target/74563] Fix return patterns for MIPS16

As Maciej reports in PR 74563, we currently generate incorrect code for mips16 (classic) non-leaf function returns. Specifically we sometimes generate jr $31, when we should be generating jr $7 (and there are times when we want to generate jr $31). The problem as Maciej and I independently co

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

On 04/18/2017 09:14 AM, Jakub Jelinek wrote: Hi! As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on ARRAY_TYPEs to denote types that need the special C++ alias handling. The problem is how is that created, we just use build_array_type and set TYPE_TYPELESS_STORAGE on the result, bu

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

On April 18, 2017 5:14:30 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on >ARRAY_TYPEs to denote types that need the special C++ alias handling. >The problem is how is that created, we just use build_array_type and >set TYPE_TYPELESS_STOR

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

On Wed, Apr 19, 2017 at 07:45:36AM +0200, Richard Biener wrote: > >As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on > >ARRAY_TYPEs to denote types that need the special C++ alias handling. > >The problem is how is that created, we just use build_array_type and > >set TYPE_TYPELESS_S

[patch] Fix PR tree-optimization/80426

Hi, this is a regression on the mainline, but the underlying issue is present on the branches too, and similar to PR tree-optimization/79666, but this time for the invariant part instead of the symbolic one. In extract_range_from_binary_expr_1, when the invariant part of the symbolic computati

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

On Wed, Apr 19, 2017 at 07:56:30AM +0200, Jakub Jelinek wrote: > On Wed, Apr 19, 2017 at 07:45:36AM +0200, Richard Biener wrote: > > >As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on > > >ARRAY_TYPEs to denote types that need the special C++ alias handling. > > >The problem is how i

Re: [PATCH] Fix fixincludes for canadian cross builds

On 18 April 2017 at 20:17, Bernd Edlinger wrote: > On 04/14/17 12:29, Bernd Edlinger wrote: >> Hi RMs: >> >> I am sorry that this happened so close to the imminent gcc-7 release >> date. >> >> To my best knowledge it would be fine to apply this update patch on the >> trunk: https://gcc.gnu.org/ml/