[Patch ARM-AArch64/testsuite Neon intrinsics 02/13] Add vqmovun tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqmovun.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqmovun.c new file mode 100644 index 000..d744765 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqmovun.c @@ -0,0 +1,93 @@ +#include +#in

[Patch ARM-AArch64/testsuite Neon intrinsics 05/13] Add vqrdmulh_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_n.c new file mode 100644 index 000..fdc739c --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_n.c @@ -0,0 +1,155 @@ +#inc

[Patch ARM-AArch64/testsuite Neon intrinsics 04/13] Add vqrdmulh_lane tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_lane.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_lane.c new file mode 100644 index 000..2235e74 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrdmulh_lane.c @@ -0,0 +1,16

[Patch ARM-AArch64/testsuite Neon intrinsics 07/13] Add vqrshrn_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrn_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrn_n.c new file mode 100644 index 000..5a20d98 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrn_n.c @@ -0,0 +1,174 @@ +#includ

[Patch ARM-AArch64/testsuite Neon intrinsics 10/13] Add vqshl_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl_n.c new file mode 100644 index 000..92a5e0d --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl_n.c @@ -0,0 +1,234 @@ +#include +#i

[Patch ARM-AArch64/testsuite Neon intrinsics 08/13] Add vqrshrun_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrun_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrun_n.c new file mode 100644 index 000..f5e431e --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshrun_n.c @@ -0,0 +1,189 @@ +#inc

[Patch ARM-AArch64/testsuite Neon intrinsics 11/13] Add vqshlu_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshlu_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshlu_n.c new file mode 100644 index 000..a6710ef --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshlu_n.c @@ -0,0 +1,263 @@ +#include

[Patch ARM-AArch64/testsuite Neon intrinsics 06/13] Add vqrshl tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshl.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshl.c new file mode 100644 index 000..3f0cb37 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqrshl.c @@ -0,0 +1,1090 @@ +#include +#inc

[Patch ARM-AArch64/testsuite Neon intrinsics 12/13] Add vqshrn_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrn_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrn_n.c new file mode 100644 index 000..b3556f4 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrn_n.c @@ -0,0 +1,177 @@ +#include

[Patch ARM-AArch64/testsuite Neon intrinsics 09/13] Add vqshl tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl.c new file mode 100644 index 000..f5a3084 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshl.c @@ -0,0 +1,829 @@ +#include +#include

[Patch ARM-AArch64/testsuite Neon intrinsics 13/13] Add vqshrun_n tests.

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrun_n.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrun_n.c new file mode 100644 index 000..ce1a3ff --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqshrun_n.c @@ -0,0 +1,133 @@ +#includ

Re: [patch, fortran] Fix PR 66111

Hello, Le 12/05/2015 22:07, Thomas Koenig a écrit : > Hello world, > > this patch fixes a regression from the inline matmul patch by > not inlining a case that is not yet handled, namely vector > subscripts. > > Regression-tested. OK for trunk? > OK with... > > Index: frontend-passes.c >

Re: [PATCH][PR66010] Don't take address of ap unless necessary

On 05/12/2015 06:45 AM, Tom de Vries wrote: Hmm, this causes an ice for s390 in gcc.dg/tree-ssa/stdarg-2.c: ... gimplification failed: &ap type 0x7f132f46b888 __va_list_tag> sizes-gimplified BLK size unit size align 32 symtab 0 alias set

Re: [PATCH 1/3] Implement -Wmisleading-indentation (v4)

On Mon, 2015-05-11 at 15:23 -0600, Jeff Law wrote: > On 04/28/2015 06:02 PM, David Malcolm wrote: > > This is an updated implementation of the proposed > > -Wmisleading-indentation warning. > > > > Changes since last patch: > > > > * I've rewritten it to use Manuel's approach from > > https://

Re: [PATCH 1/3] Implement -Wmisleading-indentation (v4)

On Tue, 2015-05-12 at 17:21 -0400, David Malcolm wrote: [...] > Thanks; I've removed the new warning from -Wall, making the appropriate > trivial doc changes, and committed it to trunk (r223098; attached). ...having bootstrapped®rtested it on x86_64-unknown-linux-gnu (Fedora 20).

RE: [RFC]: Remove Mem/address type assumption in combiner

> -Original Message- > From: Steve Ellcey [mailto:sell...@imgtec.com] > Sent: Tuesday, May 12, 2015 12:51 PM > To: Kumar, Venkataramanan > Cc: Segher Boessenkool; Jeff Law (l...@redhat.com); gcc- > patc...@gcc.gnu.org; maxim.kuvyr...@linaro.org; Matthew Fortune; > Moore, Catherine > Subje

Re: [Patch, fortran, pr65548, 2nd take, v3] [5/6 Regression] gfc_conv_procedure_call

Hello, Le 30/04/2015 15:07, Andre Vehreschild a écrit : > Hi all, > > this is just a service release. I encountered that the new testcase in the > previous release included the testcase of the initial patch, that is > already on trunk. I therefore replaced the testcase allocate_with_source_5.f90

Re: [PATCH][expr.c] PR 65358 Avoid clobbering partial argument during sibcall

On 05/11/2015 03:28 AM, Kyrill Tkachov wrote: The more I think about this, the more I think it's an ugly can of worms and maybe we should just disable sibcalls for partial arguments. I doubt it's a big performance issue in general. We already have quite a bit of code in calls.c to detect cases

Work around PR65873

Hi, this patch works around PR where we refuse to inline always_inline memcpy into function with explicit Ofast optimization attribute. This is because we think we can not promote -fno-fast-math code to -fast-math code. This is of course safe for memcpy because it contains to fast-math code, but

gccgo patch committed: If unary & does not escape, variable does not escape

This patch to the Go frontend notes that if a unary & of a variable was marked as not escaping, then we don't need to set it to be escaping based on the variable. Bootstrapped and ran ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r d50f4d14cfec go/expressions.cc

RE: [PATCH, FT32] initial support

> On 05/08/2015 06:04 PM, James Bowman wrote: > > > >> Are you using LRA or reload? The former is definitely preferred and for > >> a simple target like this, I'd expect the transition to be very easy. > > > > I'm using reload. Attempting to naively switch on LRA resulted in > >internal compil

Re: [PATCH, FT32] initial support

On 05/12/2015 04:17 PM, James Bowman wrote: On 05/08/2015 06:04 PM, James Bowman wrote: Are you using LRA or reload? The former is definitely preferred and for a simple target like this, I'd expect the transition to be very easy. I'm using reload. Attempting to naively switch on LRA resulte

Re: [PATCH, FT32] initial support

On May 12, 2015, at 3:36 PM, Jeff Law wrote: > > It really depends on the complexity of getting LRA working for the target and > given what I saw when looking at the port, I don't believe it should be much > work. LRA should default to on? Only preexisting ports about ask for, and get non-LR

Re: [PATCH, FT32] initial support

On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote: > It seems that with whenever a function's frame is bigger than 512 bytes, > LRA loops. Likely this causes a problem because there is no actual > instruction for subtracting constants more than 512. However, there is a > "link" pattern

Re: PATCHes to help with C++11 bootstrap

On 05/11/2015 07:30 AM, Markus Trippelsdorf wrote: On 2015.05.08 at 23:30 -0500, Jason Merrill wrote: One C++11 compatibility issue that turns up a lot in the GCC sources is that in C++98, #define BAR "bar" const char *p = "foo"BAR; There was a missing fix for gcc/config/rs6000/option-default

Partial fix for PR66047

Hi, this patch works around quite nasty issue where we compile function with SSE calling convention because it is local, but it is called from function that does nothave SSE (by target attribute or LTO merging). We used to produce silent wrong code here for years, but I added error to block this.

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

> From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, May 13, 2015 4:05 AM > OK for the trunk. > > Thanks for your patience, Thanks. Committed with the added "PR rtl-optimization/64616" to both ChangeLog entries. Best regards, Thomas

Re: [PATCH][PR66010] Don't take address of ap unless necessary

On 05/12/2015 01:45 PM, Tom de Vries wrote: > On 12-05-15 12:04, Tom de Vries wrote: >> Committed with comments below added. > > Hmm, this causes an ice for s390 in gcc.dg/tree-ssa/stdarg-2.c: > ... > gimplification failed: > &ap type type 0x7f132f46b888 __va_list_tag> >

Re: [PATCH][MIPS] Enable load-load/store-store bonding

Hi Mike, Thanks for your comments. Please find my comments inlined. - Thanks and regards, Sameera D. On Monday 11 May 2015 10:09 PM, Mike Stump wrote: On May 11, 2015, at 4:05 AM, sameera wrote: +(define_insn "*join2_loadhi" + [(set (match_operand:SI 0 "register_operand" "=r") + (an

[PATCH] Backport fix for PR 64839 to GCC5 (commited)

On 04/13/2015 12:04 PM, Yury Gribov wrote: On 04/13/2015 12:03 PM, Yury Gribov wrote: Hi all, I've submitted a libsanitizer cherry-pick from LLVM to not require xdr.h on systems where it's not available. Pre-approved by Jakub in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 . Forgot to a

[PATCH, 2/5] check_GNU_style.sh: Check file presence

Hi, this patch checks that the files specified on the check_GNU_style.sh command line are present. OK for trunk? Thanks, - Tom [PATCH 2/5] check_GNU_style.sh: Check file presence 2015-05-11 Tom de Vries * check_GNU_style.sh: Check if files exists. --- contrib/check_GNU_style.sh | 7 ++

[PATCH, 1/5] check_GNU_style.sh: Don't use filename prefix for one patch

Hi, this patch makes sure that we don't print the patch filename in front of the error messages, if we're checking just one file. Making the lines shorter makes things easier to read. And since we're only processing one file, there's no information lost. OK for trunk? Thanks, - Tom [PATCH

[PATCH, 3/5] check_GNU_style.sh: Read either from stdin, or from files

Hi, this patch makes sure we either handle: ... $ cat temp.patch | ./check_GNU_style.sh - ... or ... $ ./check_GNU_style.sh temp.patch ... but not: ... $ cat temp.patch | ./check_GNU_style.sh - temp2.patch ... OK for trunk? Thanks, - Tom [PATCH 3/5] check_GNU_style.sh: Read either from stdin,

[PATCH, 4/5] check_GNU_style.sh: Put stdin into temp file

Hi, this patch makes sure we dump stdin into a file before we handle it in the rest of the script. This makes the stdin handling more like the handling of normal files. OK for trunk? Thanks, - Tom [PATCH 4/5] check_GNU_style.sh: Put stdin into temp file 2015-05-11 Tom de Vries * check_

[PATCH, 5/5] check_GNU_style.sh: Fix tab size in 80 characters check

Hi, this patch fixes a problem in the 80 characters length check. Currently tab width is not properly calculated. The patch uses expand to interpret tabs properly. OK for trunk? Thanks, - Tom [PATCH 5/5] check_GNU_style.sh: Fix tab size in 80 characters check 2015-05-11 Tom de Vries *

[PATCH] Handle multiple vector sizes in BB vectorization

Well, not really - but at least don't fail vectorization because of that but allow it to proceed the "build up from scalar pieces" path. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2015-05-12 Richard Biener * tree-vect-slp.c (vect_build_slp_tree_1

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

On 05/08/2015 01:22 PM, Bernd Edlinger wrote: > On Thu, 7 May 2015 18:52:52, Michael Haubenwallner wrote: >> On 05/06/2015 03:01 PM, Bernd Edlinger wrote: >>> On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?

Re: [PATCH][PR66010] Don't take address of ap unless necessary

On Mon, 11 May 2015, Tom de Vries wrote: > On 11-05-15 09:47, Richard Biener wrote: > > > Bootstrapped and reg-tested on x86_64, with and without -m32. > > > > > > > >OK for trunk? > > > > > > > >[ FWIW, I suspect this patch will make life easier for the > > > reimplementation of > > > >the pass_s

[Ada] Visibility of a generic grand-child unit instantiated in its parent.

This patch fixes a spurious error when a generic grand-child unit is instantiated in the body of its parent, i.e. a generic child unit, and the name of the grand-child is fully qualified with that of its ancestors. The following must compile quietly: gnatmake -q c --- with A; procedure C is

[Ada] Fix undetected overflow case in Ada.Real_Time."/"

Despite the explicit pragma Unsuppress statements, the case of dividing Time_Span_First by -1 did not raise an exception. Eventually this should be corrected at the compiler or runtime level, but for now, we add an explicit check to ensure that this case is caught. The following test program:

RE: [PATCH, combine] Try REG_EQUAL for nonzero_bits

> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > > Based on my understanding of your answer quoted above, I'll commit > it as is, despite not having been able to come up with a testcase. I'll > wait tomorrow to do so though in case y

[Ada] Implement new pragma Ignore_Pragma

This implements a new configuration pragma Ignore_Pragma (IDENTIFIER) which causes any subsequent occurrences of pragma IDENTIFIER (...) to be completely ignored. The following test program compiles as shown: 1. procedure IgnorePR is 2. begin 3.pragma Ignore_Pragma; |

[Ada] Shadow entity of class-wide types

This patch performs a minor improvement to infrastructure of the frontend consisting in the unconditional construction of a shadow entity associated with the class-wide entity of tagged types (previously the shadow entity was only built by the frontend only if the real entity was not available). T

Re: [PATCH 2/6] combine: If recog fails, try again with zero_ext{ract,end} simplified

Hi Segher, On 10/05/15 17:13, Segher Boessenkool wrote: Combine has its own ideas of what is "canonical" RTL, forcing all backends to have special patterns in their machine description for the "more simplified" patterns combine often creates, even though the backend already has patterns for a mo

[Ada] Handling of object declarations with aggregates and specified alignment.

When an object declaration for an array object includes an aggregate expression and the aspect Alignment is specified for the object, the object must be initialized with an explicit assignment at the point the object is frozen. Such special processing was developed for address clauses, but it must

Re: [patch] Perform anonymous constant propagation during inlining

On Mon, May 11, 2015 at 4:05 PM, Eric Botcazou wrote: >> >Would you be OK with a slight variation of your earlier idea, i.e. >> >calling fold_stmt with a specific valueizer from fold_marked_statements >> >instead of the implicit no_follow_ssa_edges in the inliner? Something >> >like: >> > >> >tre

Re: [patch 1/28] top-level: Use automake-1.11.6

On 05/11/2015 07:55 PM, Joseph Myers wrote: > On Sat, 9 May 2015, Bernd Edlinger wrote: > >> But maybe you would like it better if we update, for instance, to: >> automake-1.14 _and_ autoconf-2.69 ? > > Updating to current automake and autoconf release versions (but still > using git versions

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On 11/05/15 20:44, Martin Galvan wrote: On Mon, May 11, 2015 at 4:45 AM, Ramana Radhakrishnan wrote: sorry about the slow response, I was travelling for a bit and missed your emails. Trying your patch out gives me failures possibly because my mail client munged it when it received this inlin

<    1   2