[PATCH] Fix segfault on verify_dominators error path

Committed as obvious. If the next check also fails, an attempt is made to print imm_bb->index. * dominance.c (verify_dominators): Don't segfault on NULL imm_bb. Index: gcc/dominance.c === --- gcc/dominance.c (revision

Re: Dominance related breakage, was Re: [PATCH] PR71275 ira.c bb_loop_depth

On Thu, May 26, 2016 at 11:04:41PM -0400, Vladimir Makarov wrote: > On 05/26/2016 10:14 PM, Alan Modra wrote: > >On Thu, May 26, 2016 at 10:12:14AM -0400, Vladimir Makarov wrote: > >>On 05/26/2016 07:02 AM, Alan Modra wrote: > >>>This fixes lack of bb_loop_depth info in some of the early parts of

Re: [PATCH][AArch64] Use aarch64_fusion_enabled_p to check for insn fusion capabilities

On 05/27/16 11:59, Kyrill Tkachov wrote: Hi all, This patch is a small cleanup that uses the newly introduced aarch64_fusion_enabled_p predicate to check for what fusion opportunities are enabled for the current target. Tested on aarch64-none-elf. Ok for trunk? Thanks, Kyrill 2016-05-27

Re: [PATCH 3/3][AArch64] Emit division using the Newton series

On 05/25/16 11:16, James Greenhalgh wrote: On Wed, Apr 27, 2016 at 04:15:53PM -0500, Evandro Menezes wrote: gcc/ * config/aarch64/aarch64-protos.h (tune_params): Add new member "approx_div_modes". (aarch64_emit_approx_div): Declare new function. *

Re: [PATCH 2/3][AArch64] Emit square root using the Newton series

On 05/25/16 10:52, James Greenhalgh wrote: On Wed, Apr 27, 2016 at 04:15:45PM -0500, Evandro Menezes wrote: gcc/ * config/aarch64/aarch64-protos.h (aarch64_emit_approx_rsqrt): Replace with new function "aarch64_emit_approx_sqrt". (tune_params): New member

Re: [PATCH 1/3][AArch64] Add more choices for the reciprocal square root approximation

On 05/25/16 05:15, James Greenhalgh wrote: On Wed, Apr 27, 2016 at 04:13:33PM -0500, Evandro Menezes wrote: gcc/ * config/aarch64/aarch64-protos.h (AARCH64_APPROX_MODE): New macro. (AARCH64_APPROX_{NONE,SP,DP,DFORM,QFORM,SCALAR,VECTOR,ALL}): Likewise.

Re: [PATCH v4] gcov: Runtime configurable destination output

On 05/26/16 13:08, Aaron Conole wrote: The previous gcov behavior was to always output errors on the stderr channel. This is fine for most uses, but some programs will require stderr to be untouched by libgcov for certain tests. This change allows configuring the gcov output via an environment

Re: [PTX] malloc/realloc/free

On 05/26/16 13:08, Alexander Monakov wrote: Hello, On Thu, 26 May 2016, Nathan Sidwell wrote: This patch removes the malloc/realloc/free wrappers from libgcc. I've implemented them completely in C and put them in the ptx newlib port -- where one expects such functions. It appears that

[wwwdocs] readings.html -- www.fh-jena.de -> www.eah-jena.de

Applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.247 diff -u -r1.247 readings.html --- readings.html 27 May 2016 20:09:51 - 1.247 +++ readings.html

[wwwdocs] projets/gupc.html -- www.gwu.edu now uses https

Applied. Gerald Index: gupc.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/gupc.html,v retrieving revision 1.9 diff -u -r1.9 gupc.html --- gupc.html 28 Aug 2015 19:50:33 - 1.9 +++ gupc.html 27 May 2016 20:42:59

[patch] config.gcc FreeBSD ARM

Hi all, The FreeBSD ARM people eliminated the extra armv6hf target and moved the hardfloat 'functionality' into the armv6-*-freebsd11+ target. This applies / will apply (FreeBSD11 is not released yet. Planned date in September 16) to FreeBSD11. On FreeBSD10 armv6 still has only soft float.

[wwwdocs] Update boehm-gc master sources in codingconventions.html

This updates the upstream web site and contact address for boehm-gc, based on feedback from Hans. (Thank you!) Committed. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v

[PATCH] Fix missing/wrong function declaration in s-osinte-rtems.ads (ada/71317)

Hello, this patch fixes the build failures of recent gnat compiler version for RTEMS targets (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71317). Attached are patches for trunk, gcc-5-branch and gcc-6-branch. I don't have write access to the svn, so if the patches pass the review process

[wwwdocs] Update upstream Go repository in doc/sourcebuild.texi

The guys managing code.google.com put a nice redirect in place, just following this. I'll probably push this back to GCC 6 as well in a while. Committed. Gerald 2016-05-27 Gerald Pfeifer * doc/sourcebuild.texi: New address for upstream Go repository. Index:

[wwwdocs] Remove developer.intel.com link from readings.html

Intel's web team had this now redirect to a general product page (for hardware). With such an approach, I don't want to link to them directly any longer -- people can just google for whatever the location of the day of manuals etc. may be. Applied. Gerald Index: readings.html

[wwwdocs] testing/testing-blitz.html -- sourceforge.net uses https

Committed. Gerald Index: testing/testing-blitz.html === RCS file: /cvs/gcc/wwwdocs/htdocs/testing/testing-blitz.html,v retrieving revision 1.6 diff -u -r1.6 testing-blitz.html --- testing/testing-blitz.html 1 Nov 2012 18:40:09

[PATCH, rs6000] Add builtin-support for new Power9 vslv and vsrv (vector shift left and right variable) instructions

This patch adds built-in function support for the Power9 vslv and vsrv instructions. I have bootstrapped and tested this patch against the trunk on powerpc64le-unkonwn-linux-gnu with no regressions. Is this ok for the trunk? I have not yet tested against the gcc-6 branch as this patch depends

Re: [wwwdocs] Document GCC 6 Solaris changes

On Tue, 19 Apr 2016, Rainer Orth wrote: >>> [gcc-6/changes.html] > Btw., I noticed that the subsections of `Operating Systems' are in > random order. Shouldn't they be sorted alphabetically? Yes. Want to give it a try? It's surely pre-approved. Gerald

[wwwdocs] Update to current canonical address for CSiBE

Applied. Gerald Index: benchmarks/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/benchmarks/index.html,v retrieving revision 1.34 diff -u -r1.34 index.html --- benchmarks/index.html 27 Feb 2016 22:43:31 - 1.34 +++

[wwwdocs] www.akkadia.org now uses https -- gcc-4.0/changes.html

Applied. Gerald Index: gcc-4.0/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v retrieving revision 1.67 diff -u -r1.67 changes.html --- gcc-4.0/changes.html27 Jun 2015 19:26:46 - 1.67 +++

Re: Record likely upper bounds for loops

Hi, On 27/05/2016 19:20, Alexander Monakov wrote: Hi, On Fri, 27 May 2016, Jan Hubicka wrote: Thanks, updatted and comitted. This checkin seems to regress gcc.c-torture/execute/20050826-2.c at -Os: gcc/xgcc -Bgcc/ ../gcc/gcc/testsuite/gcc.c-torture/execute/20050826-2.c -Os \ -o

Re: [PATCH] Fixes to must-tail-call tests

On Fri, 2016-05-27 at 13:29 +0100, Thomas Preudhomme wrote: > Hi Rainer, > > On Wednesday 25 May 2016 11:31:12 Rainer Orth wrote: > > David Malcolm writes: > > > The following fixes the known failures of the must-tail-call > > > tests. > > > > > > Tested with --target= > >

[PATCH] c/69507 - bogus warning: ISO C does not allow ‘__alignof__ (expression)’

The patch below adjusts the C alignof pedantic warning to avoid diagnosing the GCC extension (__alignof__) and only diagnose _Alignof in C99 and prior modes. This is consistent with how __attribute__ ((aligned)) and _Alignas is handled (among other extensions vs standard features). Martin PR

Re: [PATCH1][PR71252] Fix missing swap to stmt_to_insert

On May 27, 2016 4:12:06 PM GMT+02:00, Kugan Vivekanandarajah wrote: >Hi, > >This fix the missing swap for stmt-to_insert. I tested this with the >attached test case which is not valid any more due to some other >commits. This I believe an is obvious fix and

Re: Record likely upper bounds for loops

Hi, On Fri, 27 May 2016, Jan Hubicka wrote: > Thanks, updatted and comitted. This checkin seems to regress gcc.c-torture/execute/20050826-2.c at -Os: gcc/xgcc -Bgcc/ ../gcc/gcc/testsuite/gcc.c-torture/execute/20050826-2.c -Os \ -o ./20050826-2.exe ./20050826-2.exe Aborted (the previous

Re: [C++ Patch/RFC] PR 60385 and other issues about wrongly named namespaces (eg, c++/68723)

Hi, On 27/05/2016 16:56, Jason Merrill wrote: Let's go with the second patch. Good. Then I'm going to commit the below after an additional round of testing with an updated tree. Thanks! Paolo. /// /cp 2016-05-27 Paolo Carlini PR

[PATCH][AArch64] Use aarch64_fusion_enabled_p to check for insn fusion capabilities

Hi all, This patch is a small cleanup that uses the newly introduced aarch64_fusion_enabled_p predicate to check for what fusion opportunities are enabled for the current target. Tested on aarch64-none-elf. Ok for trunk? Thanks, Kyrill 2016-05-27 Kyrylo Tkachov

[PATCH][AArch64] Remove aarch64_simd_attr_length_move

Hi all, I notice that we can do without aarch64_simd_attr_length_move. The move alternatives for the OI,CI,XImode modes that involve memory operands all use a single load/store so are always length 4, whereas the register-to-register moves have a statically-known length of (GET_MODE_BITSIZE

Re: [AArch64, 1/6] Reimplement scalar fixed-point intrinsics

On 27/05/16 14:03, James Greenhalgh wrote: On Tue, May 24, 2016 at 09:23:36AM +0100, Jiong Wang wrote: * config/aarch64/aarch64-simd-builtins.def: Rename to aarch64-builtins.def. Why? We already have some number of intrinsics in here that are not strictly SIMD, but I don't

Re: [AArch64, 3/6] Reimplement frsqrte intrinsics

On 27/05/16 14:24, James Greenhalgh wrote: On Tue, May 24, 2016 at 09:23:48AM +0100, Jiong Wang wrote: These intrinsics were implemented before the instruction pattern "aarch64_rsqrte" added, that these intrinsics were implemented through inline assembly. This mirgrate the implementation to

[PATCH] c++/71306 - bogus -Wplacement-new with an array element

It was pointed out on gcc-help last night that the -Wplacement-new warning issues a false positive when a placement new expression is invoked with an operand that is an element of an array of pointers (to buffers of unknown size). The attached patch adjusts the warning so as to avoid this false

Moving backwards/FSM threader into its own pass

It's been my plan since finally wrapping my head around Bodik's thesis to revamp how we handle jump threading to use some of the principles from his thesis. In particular, the back substitution and simplification model feels like the right long term direction. Sebastian's FSM threader was

Re: [C++ PATCH] PR c++/69855

On Fri, May 27, 2016 at 11:20 AM, Ville Voutilainen wrote: > On 27 May 2016 at 17:46, Jason Merrill wrote: >> OK, thanks. > Should this fix be backported to the gcc6-branch? I have no plans to > backport it any further than that. No, the bug isn't

Re: Enable loop peeling at -O3

On 05/27/2016 07:19 AM, Jan Hubicka wrote: [snip] Index: doc/invoke.texi === --- doc/invoke.texi (revision 236815) +++ doc/invoke.texi (working copy) @@ -8661,10 +8661,17 @@ the loop is entered. This usually makes @item

[PATCH2][PR71252] Fix insertion point of stmt_to_insert

Hi Richard, This fix insertion point of stmt_to_insert based on your comments. In insert_stmt_before_use , I now use find_insert_point such that we insert the stmt_to_insert after its operands are defined. This means that we now have to insert before and insert after in other cases. I also

[gomp4.5] Partial support for Fortran OpenMP doacross loops

Hi! I've committed the following patch to gomp-4_5-branch, which contains initial version of doacross Fortran support. No testcase yet, as only simple loops (ones with constant 1 or -1 step) work right now, for non-simple ones (variable step or non-1/-1 step) I'll need to add some middle-end

Re: [C++ PATCH] PR c++/69855

On 27 May 2016 at 17:46, Jason Merrill wrote: > OK, thanks. Should this fix be backported to the gcc6-branch? I have no plans to backport it any further than that. > > Jason > > > On Fri, May 27, 2016 at 10:43 AM, Ville Voutilainen > wrote: >> On

[gomp4] backport firstprivate subarray changes

This patch backports the recent firstprivate subarray changes I've made to trunk. Gomp4 has preliminary support for c++ reference types, so I had to make some adjustments to the original patch to get this.C and non-scalar-data.C working. Those changes were relatively minor, so I'll bring them to

Re: [PATCH][2/3] Vectorize inductions that are live after the loop

On 27/05/2016 12:41, "Richard Biener" wrote: >On Fri, May 27, 2016 at 11:09 AM, Alan Hayward >wrote: >> This patch is a reworking of the previous vectorize inductions that are >> live >> after the loop patch. >> It now supports SLP and an

[visium] Split DImode arithmetical operations

This makes it so that DImode arithmetical operations are split into a pair of SImode operations in order to enable better scheduling. Tested on visium-elf, applied on the mainline and 6 branch. 2016-05-27 Eric Botcazou * config/visium/visium-protos.h

Re: [C++ Patch/RFC] PR 60385 and other issues about wrongly named namespaces (eg, c++/68723)

Let's go with the second patch. Jason

Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

Andre Vieira (lists) wrote: > On 07/04/16 10:30, Andre Vieira (lists) wrote: > > On 17/03/16 16:33, Andre Vieira (lists) wrote: > >> On 23/10/15 12:31, Bernd Schmidt wrote: > >>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote: > > Index: gcc/configure.ac >

[C++ Patch/RFC] PR 60385 and other issues about wrongly named namespaces (eg, c++/68723)

Hi, we have these long standing issues with code like (c++/60385): float foo4(); namespace foo4 { // } where the name of the namespace conflicts with an existing declaration. Error recovery is currently suboptimal, for example, c++/60385 is about struct bar6 { friend

Re: [C++ PATCH] PR c++/69855

OK, thanks. Jason On Fri, May 27, 2016 at 10:43 AM, Ville Voutilainen wrote: > On 20 May 2016 at 07:05, Ville Voutilainen > wrote: >> On 19 May 2016 at 19:40, Jason Merrill wrote: >>> Any thoughts on doing something

[gomp4] backport gfc_match_omp_clauses restructuring changes

This patch backports the gfc_match_omp_clauses restructuring changes that occurred early this month in trunk to gomp-4_0-branch. Now it's easier to detect which of our local changes in gomp4 are not present in trunk yet. Cesar 2016-05-27 Cesar Philippidis Backport

Re: [C++ PATCH] PR c++/69855

On 20 May 2016 at 07:05, Ville Voutilainen wrote: > On 19 May 2016 at 19:40, Jason Merrill wrote: >> Any thoughts on doing something similar for extern variable declarations? > > Ah, we diagnose local extern variable declarations that clash with >

Re: Further refinement to -Wswitch-unreachable

On 05/26/2016 02:44 PM, Marek Polacek wrote: + if (gimple_code (stmt) == GIMPLE_TRY) { + /* A compiler-generated cleanup or a user-written try block. +Try to get the first statement in its try-block, for better +location. */ +

[PATCH1][PR71252] Fix missing swap to stmt_to_insert

Hi, This fix the missing swap for stmt-to_insert. I tested this with the attached test case which is not valid any more due to some other commits. This I believe an is obvious fix and maybe the test case is needed. I am running bootstrap and regression testing on x86-64-linux gnu. Is this OK for

[gomp4] fix bootstrap failure in oacc_loop_auto_partitions

This patch fixes a bootstrap failure that I encountered while backporting the firstprivate subarray patch to gomp-4_0-branch. I've applied it to gomp4. Cesar 2016-05-27 Cesar Philippidis * gcc/omp-low.c (oacc_loop_auto_partitions): Use boolean OR when comparing

Re: Enable loop peeling at -O3

> > @@ -0,0 +1,11 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O3 -fdump-tree-loop-ivcanon" } */ > > This should probably be -fdump-tree-ivcanon-details. Yep, I updated the testcaes in my tree. > > > +struct foo {int b; int a[3];} foo; > > +void add(struct foo *a,int l) > > +{ > > +

Re: [AArch64, 4/6] Reimplement frsqrts intrinsics

On 27/05/16 14:25, James Greenhalgh wrote: On Tue, May 24, 2016 at 09:23:53AM +0100, Jiong Wang wrote: Similar as [3/6], these intrinsics were implemented before the instruction pattern "aarch64_rsqrts" added, that these intrinsics were implemented through inline assembly. This mirgrate the

Re: Enable loop peeling at -O3

On Fri, May 27, 2016 at 03:19:29PM +0200, Jan Hubicka wrote: > Hi, > this patch enabled -fpeel-loops by default at -O3 and makes it to use likely > upper bound estimates. The patch also adds -fpeel-all-loops flag that is > symmetric to -funroll-all-loops. Long time ago we used to interpret >

[PATCH][AArch64] Enable -frename-registers at -O2 and higher

Hi all, As mentioned in https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00297.html, frename-registers registers can be beneficial for aarch64 and the patch at https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01618.html resolves the AESE/AESMC fusion issue that it exposed in the aarch64 backend. So

Re: [AArch64, 5/6] Reimplement fabd intrinsics & merge rtl patterns

On 27/05/16 14:31, James Greenhalgh wrote: On Tue, May 24, 2016 at 09:23:58AM +0100, Jiong Wang wrote: These intrinsics were implemented before "fabd_3" introduces. Meanwhile the patterns "fabd_3" and "*fabd_scalar3" can be merged into a single "fabd3" using VALLF. This patch migrate the

Re: [AArch64, 6/6] Reimplement vpadd intrinsics & extend rtl patterns to all modes

On 27/05/16 14:42, James Greenhalgh wrote: On Tue, May 24, 2016 at 09:24:03AM +0100, Jiong Wang wrote: These intrinsics was implemented by inline assembly using "faddp" instruction. There was a pattern "aarch64_addpv4sf" which supportsV4SF mode only while we can extend this pattern to support

Re: [PATCH][ARM] Tie operand 1 to operand 0 in AESMC pattern when fusing AES/AESMC

On 20/05/16 11:04, Kyrill Tkachov wrote: Hi all, The recent -frename-registers change exposed a deficiency in the way we fuse AESE/AESMC instruction pairs in arm. Basically we want to enforce: AESE Vn, _ AESMC Vn, Vn to enable the fusion, but regrename comes along and renames the

Re: [AArch64, 6/6] Reimplement vpadd intrinsics & extend rtl patterns to all modes

On Tue, May 24, 2016 at 09:24:03AM +0100, Jiong Wang wrote: > These intrinsics was implemented by inline assembly using "faddp" > instruction. > There was a pattern "aarch64_addpv4sf" which supportsV4SF mode only > while we can > extend this pattern to support VDQF mode, then we can reimplement

Re: [PATCH][AArch64] Tie operand 1 to operand 0 in AESMC pattern when AES/AESMC fusion is enabled

On 26/05/16 11:17, James Greenhalgh wrote: On Fri, May 20, 2016 at 11:04:32AM +0100, Kyrill Tkachov wrote: Hi all, The recent -frename-registers change exposed a deficiency in the way we fuse AESE/AESMC instruction pairs in aarch64. Basically we want to enforce: AESE Vn, _ AESMC

Re: [AArch64, 5/6] Reimplement fabd intrinsics & merge rtl patterns

On Tue, May 24, 2016 at 09:23:58AM +0100, Jiong Wang wrote: > These intrinsics were implemented before "fabd_3" introduces. > Meanwhile > the patterns "fabd_3" and "*fabd_scalar3" can be merged into a > single "fabd3" using VALLF. > > This patch migrate the implementation to builtins backed by

Re: [AArch64, 3/6] Reimplement frsqrte intrinsics

On Tue, May 24, 2016 at 09:23:48AM +0100, Jiong Wang wrote: > These intrinsics were implemented before the instruction pattern > "aarch64_rsqrte" added, that these intrinsics were implemented through > inline assembly. > > This mirgrate the implementation to builtin. > > gcc/ > 2016-05-23 Jiong

Re: [AArch64, 4/6] Reimplement frsqrts intrinsics

On Tue, May 24, 2016 at 09:23:53AM +0100, Jiong Wang wrote: > Similar as [3/6], these intrinsics were implemented before the instruction > pattern "aarch64_rsqrts" added, that these intrinsics were implemented > through inline assembly. > > This mirgrate the implementation to builtin. > > gcc/ >

Enable loop peeling at -O3

Hi, this patch enabled -fpeel-loops by default at -O3 and makes it to use likely upper bound estimates. The patch also adds -fpeel-all-loops flag that is symmetric to -funroll-all-loops. Long time ago we used to interpret -fpeel-loops this way and blindly peel every loop but this behaviour got

Re: [PR71252][PR71269] Fix trunk errors due to stmt_to_insert

On Fri, May 27, 2016 at 2:36 PM, Kugan Vivekanandarajah wrote: > Hi Richard, > > On 27 May 2016 at 19:56, Richard Biener wrote: >> On Thu, May 26, 2016 at 11:32 AM, Kugan Vivekanandarajah >> wrote:

Re: [AArch64, 1/6] Reimplement scalar fixed-point intrinsics

On Tue, May 24, 2016 at 09:23:36AM +0100, Jiong Wang wrote: > This patch reimplement scalar intrinsics for conversion between floating- > point and fixed-point. > > Previously, all such intrinsics are implemented through inline assembly. > This patch added RTL pattern for these operations that

Re: [PATCH, ARM] Do not set ARM_ARCH_ISA_THUMB for armv5

On 27/05/16 13:51, Thomas Preudhomme wrote: On Tuesday 24 May 2016 18:00:27 Kyrill Tkachov wrote: Hi Thomas, Hi Kyrill, +/* Nonzero if chip supports Thumb. */ +extern int arm_arch_thumb; + Bit of bikeshedding really, but I think a better name would be arm_arch_thumb1. This is because we

Re: [PATCH, ARM] Do not set ARM_ARCH_ISA_THUMB for armv5

On Tuesday 24 May 2016 18:00:27 Kyrill Tkachov wrote: > Hi Thomas, Hi Kyrill, > > > > +/* Nonzero if chip supports Thumb. */ > > +extern int arm_arch_thumb; > > + > > Bit of bikeshedding really, but I think a better name would be > arm_arch_thumb1. > This is because we also have the macros

Re: [PATCH, ARM] Remove unused TARGET_ARM_V*M macros

On 27/05/16 13:32, Thomas Preudhomme wrote: Hi, TARGET_ARM_V6M and TARGET_ARM_v7M defined in gcc/config/arm/arm.h appears to be unused. This patch removes them. ChangeLog entry is obvious: *** gcc/ChangeLog *** 2016-05-23 Thomas Preud'homme *

Re: [PATCH][Testsuite] Fix mips dsp testsuite mistakes

I am wrong, I lost the sta16() in mips dsp manual.

[PATCH, ARM] Remove unused TARGET_ARM_V*M macros

Hi, TARGET_ARM_V6M and TARGET_ARM_v7M defined in gcc/config/arm/arm.h appears to be unused. This patch removes them. ChangeLog entry is obvious: *** gcc/ChangeLog *** 2016-05-23 Thomas Preud'homme * config/arm/arm.h (TARGET_ARM_V6M): Remove.

Re: [PATCH] Fixes to must-tail-call tests

Hi Rainer, On Wednesday 25 May 2016 11:31:12 Rainer Orth wrote: > David Malcolm writes: > > The following fixes the known failures of the must-tail-call tests. > > > > Tested with --target= > > * aarch64-unknown-linux-gnu > > * ia64-unknown-linux-gnu > > *

Re: Record likely upper bounds for loops

> likely_max_loop_iterations misses a function comment. Thanks, updatted and comitted. > > Ugh, one more widest_int in struct loop ... (oh well). Given > that (on x86_64) sizeof(widest_int) == 40 and sizeof(tree_int_cst) == 24 > (ok, that's cheating, it's with just one HWI for the number) it

[Committed] S/390: Replace rtx_equal_p with reg_overlap_mentioned_p in splitter check.

gcc/ChangeLog: 2016-05-27 Andreas Krebbel * config/s390/s390.md (2x risbg splitters): Use reg_overlap_mentioned_p instead of rtx_equal_p. --- gcc/ChangeLog | 5 + gcc/config/s390/s390.md | 4 ++-- 2 files changed, 7 insertions(+), 2

Re: [PATCH][AArch64] Remove aarch64_cannot_change_mode_class

James Greenhalgh wrote: > Which targets did you check? I'd hope aarch64_be-none-elf in addition to > aarch64-none-linux-gnu. I ran aarch64-none-elf, and just checked aarch64_be-none-elf passes too. > Please refer to PR67609 in your ChangeLog so this gets tracked alongside > the other fixes in

Re: Fix middle-end/71308

On Fri, May 27, 2016 at 1:52 PM, Marek Polacek wrote: > A stupid mistake of mine. When I introduced the should_remove_lhs_p call, > I removed the check for LHS here, because should_remove_lhs_p checks that. > Well, in this case the LHS was NULL, but gimple_call_fntype (stmt)

Re: RFC [1/2] divmod transform

On Fri, 27 May 2016, Prathamesh Kulkarni wrote: > On 27 May 2016 at 15:45, Richard Biener wrote: > > On Wed, 25 May 2016, Prathamesh Kulkarni wrote: > > > >> On 25 May 2016 at 12:52, Richard Biener wrote: > >> > On Tue, 24 May 2016, Prathamesh Kulkarni

Re: [PATCH PR68030/PR69710][RFC]Introduce a simple local CSE interface and use it in vectorizer

On Fri, May 27, 2016 at 1:11 PM, Bin.Cheng wrote: > On Fri, May 27, 2016 at 11:45 AM, Richard Biener > wrote: >> On Wed, May 25, 2016 at 1:22 PM, Bin Cheng wrote: >>> Hi, >>> As analyzed in PR68303 and PR69710, vectorizer

Re: Record likely upper bounds for loops

On Fri, 27 May 2016, Jan Hubicka wrote: > Hi, > this patch adds infrastructure to tree-ssa-loop-niter to record likely upper > bounds. > The basic idea is that it is easier to get likely bounds that 100% safe > bounds or > realistic estimates and the bound can be effectively used to trim down

Fix middle-end/71308

A stupid mistake of mine. When I introduced the should_remove_lhs_p call, I removed the check for LHS here, because should_remove_lhs_p checks that. Well, in this case the LHS was NULL, but gimple_call_fntype (stmt) had void type, so we went on and crashed on the SSA_NAME check. Sorry. But at

Re: RFC [1/2] divmod transform

On 27 May 2016 at 15:45, Richard Biener wrote: > On Wed, 25 May 2016, Prathamesh Kulkarni wrote: > >> On 25 May 2016 at 12:52, Richard Biener wrote: >> > On Tue, 24 May 2016, Prathamesh Kulkarni wrote: >> > >> >> On 24 May 2016 at 19:39, Richard Biener

Re: [PATCH][2/3] Vectorize inductions that are live after the loop

On Fri, May 27, 2016 at 11:09 AM, Alan Hayward wrote: > This patch is a reworking of the previous vectorize inductions that are > live > after the loop patch. > It now supports SLP and an optimisation has been moved to patch [3/3]. > > > Stmts which are live (ie: defined

Re: [PATCH, AArch64] atomics: prefetch the destination for write prior to ldxr/stxr loops

On Tue, Mar 15, 2016 at 03:31:30PM +, James Greenhalgh wrote: > On Mon, Mar 07, 2016 at 10:54:25PM -0800, Andrew Pinski wrote: > > On Mon, Mar 7, 2016 at 8:12 PM, Yangfei (Felix) > > wrote: > > >> On Mon, Mar 7, 2016 at 7:27 PM, Yangfei (Felix)

Record likely upper bounds for loops

Hi, this patch adds infrastructure to tree-ssa-loop-niter to record likely upper bounds. The basic idea is that it is easier to get likely bounds that 100% safe bounds or realistic estimates and the bound can be effectively used to trim down optimizations that are good idea only for large trip

Re: [PATCH PR68030/PR69710][RFC]Introduce a simple local CSE interface and use it in vectorizer

On Fri, May 27, 2016 at 11:45 AM, Richard Biener wrote: > On Wed, May 25, 2016 at 1:22 PM, Bin Cheng wrote: >> Hi, >> As analyzed in PR68303 and PR69710, vectorizer generates duplicated >> computations in loop's pre-header basic block when creating

Re: [PATCH PR68030/PR69710][RFC]Introduce a simple local CSE interface and use it in vectorizer

On Wed, May 25, 2016 at 1:22 PM, Bin Cheng wrote: > Hi, > As analyzed in PR68303 and PR69710, vectorizer generates duplicated > computations in loop's pre-header basic block when creating base address for > vector reference to the same memory object. Because the duplicated

Re: RFC [1/2] divmod transform

On Wed, 25 May 2016, Prathamesh Kulkarni wrote: > On 25 May 2016 at 12:52, Richard Biener wrote: > > On Tue, 24 May 2016, Prathamesh Kulkarni wrote: > > > >> On 24 May 2016 at 19:39, Richard Biener wrote: > >> > On Tue, 24 May 2016, Prathamesh Kulkarni

Re: [PATCH, PR middle-end/71279] Avoid folding vec_cond_expr into comparison

On Fri, May 27, 2016 at 11:02 AM, Ilya Enkovich wrote: > Hi, > > This patch disable transformation of VEC_COND_EXPR into comparison > which became invalid after boolean vectors introduciton. > > Bootstrapped and regtested for x86_64-pc-linux-gnu. OK for trunk > and gcc-6?

Re: [PATCH] Help PR70729, shuffle LIM and PRE

On Thu, 26 May 2016, Christophe Lyon wrote: > On 18 May 2016 at 12:55, Richard Biener wrote: > > > > The following patch moves LIM before PRE to allow it to cleanup CSE > > (and copyprop) opportunities LIM exposes. It also moves the DCE done > > in loop before the loop

Re: [PR71252][PR71269] Fix trunk errors due to stmt_to_insert

On Thu, May 26, 2016 at 11:32 AM, Kugan Vivekanandarajah wrote: > Hi Jakub, > > > On 26 May 2016 at 18:18, Jakub Jelinek wrote: >> On Thu, May 26, 2016 at 02:17:56PM +1000, Kugan Vivekanandarajah wrote: >>> --- a/gcc/tree-ssa-reassoc.c >>> +++

Re: [PATCH][2/3][AArch64] Keep CTZ components together until after reload

On Thu, May 26, 2016 at 10:53:07AM +0100, Kyrill Tkachov wrote: > Hi all, > > In a similar rationale to patch 1/3 this patch changes the AArch64 backend to > keep the CTZ expression as a single RTX until after reload when it is split > into an RBIT and a CLZ instruction. This enables

Re: [PATCH][AArch64] Simplify ashl3 expander for SHORT modes

On Wed, Apr 27, 2016 at 03:10:47PM +0100, Kyrill Tkachov wrote: > Hi all, > > The ashl3 expander for QI and HI modes is needlessly obfuscated. > The 2nd operand predicate accepts nonmemory_operand but the expand code > FAILs if it's not a CONST_INT. We can just demand a const_int_operand in > the

Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs

On Fri, 27 May 2016, Jan Hubicka wrote: > Hi, > this is version of patch which bootstrap all languages at x86_64. OK? The tree-pretty-print.c change is ok. I think the > - if (stride) > + if (stride && akind >= GFC_ARRAY_ALLOCATABLE) should include a comment. Richard. > Honza > > *

[PATCH][3/3] No need to vectorize simple only-live stmts

Statements which are live but not relevant need marking to ensure they are vectorized. Live statements which are simple and all uses of them are invariant do not need to be vectorized. This patch adds a check to make sure those stmts which pass both the above checks are not vectorized and then

[PATCH][2/3] Vectorize inductions that are live after the loop

This patch is a reworking of the previous vectorize inductions that are live after the loop patch. It now supports SLP and an optimisation has been moved to patch [3/3]. Stmts which are live (ie: defined inside a loop and then used after the loop) are not currently supported by the vectorizer.

[PATCH][1/3] Add loop_vinfo to vect_get_vec_def_for_operand

This patch simply adds loop_vinfo as an extra argument to vect_get_vec_def_for_operand and only generates a stmt_vinfo if required. This is a required cleanup for patch [2/3]. Tested on x86 and aarch64. gcc/ * tree-vectorizer.h (vect_get_vec_def_for_operand): Pass loop_vinfo in. *

[PATCH, PR middle-end/71279] Avoid folding vec_cond_expr into comparison

Hi, This patch disable transformation of VEC_COND_EXPR into comparison which became invalid after boolean vectors introduciton. Bootstrapped and regtested for x86_64-pc-linux-gnu. OK for trunk and gcc-6? Thanks, Ilya -- gcc/ 2016-05-27 Ilya Enkovich PR

Re: [PATCH][AArch64] Remove aarch64_cannot_change_mode_class

On Thu, May 19, 2016 at 12:23:32PM +0100, Wilco Dijkstra wrote: > Remove aarch64_cannot_change_mode_class as the underlying issue > (PR67609) has been resolved. This avoids a few unnecessary lane > widening operations like: > > faddp d18, v18.2d > mov d18, v18.d[0] > > Passes regress, OK

Re: [PATCH][AArch64] Delete obsolete CC_ZESWP and CC_SESWP CC modes

On Wed, Apr 27, 2016 at 03:12:10PM +0100, Kyrill Tkachov wrote: > Hi all, > > The CC_ZESWP and CC_SESWP are not used anywhere and seem to be a remmant of > some > old code that was removed. The various compare+extend patterns in aarch64.md > don't > use these modes. So it should be safe to

Re: [SPARC] Support for --with-{cpu,tune}-{32,64} in sparc*-* targets

> Tested in sparc64-linux-gnu, sparcv9-linux-gnu and sparc-sun-solaris2.11. > > 2016-05-25 Jose E. Marchesi > > * config.gcc (sparc*-*-*): Support cpu_32, cpu_64, tune_32 and > tune_64. > * doc/install.texi (--with-cpu-32, --with-cpu-64): Document >

Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs

Hi, this is version of patch which bootstrap all languages at x86_64. OK? Honza * trans-types.c (gfc_array_range_type): Remove. (gfc_init_types): Do not build gfc_array_range_type. (gfc_get_array_type_bounds): Do not put unrealistic array bounds. * trans-types.h

GCC 5 Branch is frozen

Hi, The GCC 5 branch is frozen now in preparation for a GCC 5.4 release candidate. All changes require release manager approval until after the GCC 5.4 release. Thanks, Richard.

  1   2   >