On 10/11/15 12:51, Richard Biener wrote:
>>
>> Just noticing this... if we have a vectorization factor of 4 and matches
>> is 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0 then this will split into 1, 1, 1, 1
>> and
>> 1, 1, 0, 0, 0, ... where we know from the matches that it will again fail?
>>
>> Thus sho
On 10/11/15 09:34, Richard Biener wrote:
The following fixes PR56118 by adjusting the cost model handling of
basic-block vectorization to favor the vectorized version in case
estimated cost is the same as the estimated cost of the scalar
version. This makes sense because we over-estimate the ve
On 03/11/15 14:27, Alan Lawrence wrote:
This migrates the various reduction optabs in sse.md to use the reduce-to-scalar
form. I took the straightforward approach (equivalent to the migration code in
expr.c/optabs.c) of generating a vector temporary, using the existing code to
reduce to that
The scan-assembler vclz2s 34 test in here has been failing since r230091:
* tree-vect-slp.c (vect_bb_vectorization_profitable_p): Make equal
cost favor vectorized version.
which transforms a load of piecewise array assignments (in tree) into
2-element-vector writes to MEMs, an
This follows from the discussion here:
https://gcc.gnu.org/ml/gcc/2015-10/msg00082.html .
OK for trunk?
--Alan
gcc/ChangeLog:
doc/install.texi: Add note against GNAT 4.8 on ARM targets.
---
gcc/doc/install.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/doc/install.texi
On 09/11/15 12:55, Richard Biener wrote:
Currently BB vectorization computes all dependences inside a BB
region and fails all vectorization if it cannot handle some of them.
This is obviously not needed - BB vectorization can restrict the
dependence tests to those that are needed to apply the l
On 14/11/15 00:07, Jason Merrill wrote:
And here's the final patch integrating the delayed folding branch. The general
idea is to mostly avoid folding until the end of the function, at which point we
fold everything as part of genericization. Since many warnings rely on looking
at folded trees,
On 16/11/15 14:42, Christophe Lyon wrote:
Hi Alan,
I've noticed that this new test (gcc.dg/vect/bb-slp-subgroups-3.c)
fails for armeb targets.
I haven't had time to look at more details yet, but I guess you can
reproduce it quickly enough.
Thanks - yes I see it now.
-fdump-tree-optimized lo
On 13/11/15 08:41, Richard Biener wrote:
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-11-13 Richard Biener
* tree-vect-loop.c (vect_analyze_loop_2): Add fatal parameter.
Signal fatal failure if early checks fail.
(vect_analyze
On 6 November 2015 at 10:39, Richard Biener wrote:
>> ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location
>> references block not in block tree
>> l1_279 = PHI <1(28), l1_299(33)>
>
> ^^^
>
> this is the error to look at! It means that the GC heap will be corrupted
> quit
I note doc/install.texi says that gcc uses "ISL Library version 0.15,
0.14, 0.13, or 0.12.2". This patch breaks the build with 0.12.2 (a
subset of errors below), but seems fine with 0.14. I haven't tested
0.13. Do we want to update install.texi ?
Cheers, Alan
In file included from
/work/alalaw01
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
PR libstdc++/67440
* python/libstdcxx/v6/printers.py (find_type): Handle "const" in
type name.
* testsui
On 14/11/15 13:19, David Edelsohn wrote:
The copy_ctor_neg testcase fails on AIX.
Also on ARM and AArch64 platforms (arm-none-linux-gnueabihf, arm-none-eabi,
aarch64-none-linux-gnu, aarch64-none-elf), with similar error messages.
Thanks,
Alan
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
../../binutils-gdb/
while (exceptions_state_mc_action_iter_1 ())
;
}
if (!varseen)
printf_unfiltered ();
}
On 26 November 2015 at 11:33, 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 b
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 what make check
> do
On 26 November 2015 at 14:00, Alan Lawrence wrote:
> 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
>
On 23/11/15 09:43, Richard Biener wrote:
On Fri, 20 Nov 2015, Alan Lawrence wrote:
...the asserts
you suggested in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68117#c27)...
>>
So I have to ask, how sure are you that those assertions are(/should
be!) "correct"? :)
Ideall
On 27/11/15 15:07, Alan Lawrence wrote:
On 23/11/15 09:43, Richard Biener wrote:
On Fri, 20 Nov 2015, Alan Lawrence wrote:
...the asserts
you suggested in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68117#c27)...
>>
So I have to ask, how sure are you that those assertions are(/
regressions
there...
Is this ok for trunk?
This could also be a candidate for the 5.3 release; backporting depends only on
the (fairly trivial) r230357.
gcc/ChangeLog:
Alan Lawrence
Richard Biener
* cfgexpand.c (pass_expand::execute): Replace call to
redirect_edg
On 27/11/15 14:13, Richard Biener wrote:
The following fixes the excessive peeling for gaps we do when doing
SLP now that I removed most of the restrictions on having gaps in
the first place.
This should make low-trip vectorized loops more efficient (sth
also the combine-epilogue-with-vectorize
On 24/11/15 14:55, Andreas Arnez wrote:
Ping?
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
I guess we want C and C++ behave the same here?
gcc/cp/ChangeLog:
* cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location
to start of loop body instead of start
On 02/12/15 14:13, Jeff Law wrote:
On 12/02/2015 01:33 AM, Richard Biener wrote:
Right. So the question I have is how/why did DOM leave anything in the map.
And if DOM is fixed to not leave stuff lying around, can we then assert that
nothing is ever left in those maps between passes? There's c
On 03/12/15 12:58, Richard Biener wrote:
On Thu, 3 Dec 2015, Alan Lawrence wrote:
On 02/12/15 14:13, Jeff Law wrote:
On 12/02/2015 01:33 AM, Richard Biener wrote:
Right. So the question I have is how/why did DOM leave anything in the
map.
And if DOM is fixed to not leave stuff lying around
On 16/11/15 15:08, Alan Lawrence wrote:
This follows from the discussion here:
https://gcc.gnu.org/ml/gcc/2015-10/msg00082.html .
OK for trunk?
--Alan
gcc/ChangeLog:
doc/install.texi: Add note against GNAT 4.8 on ARM targets.
---
gcc/doc/install.texi | 2 ++
1 file changed, 2
On 05/11/15 21:43, Sebastian Pop wrote:
* graphite-optimize-isl.c (optimize_isl): Call
isl_options_set_schedule_maximize_band_depth.
* gcc.dg/graphite/fuse-1.c: New.
* gcc.dg/graphite/fuse-2.c: New.
* gcc.dg/graphite/interchange-13.c: Remove bogus check.
On 27/11/15 08:30, Richard Biener wrote:
This is part 1 of a fix for PR68533 which shows that some targets
cannot can_vec_perm_p on an identity permutation. I chose to fix
this in the vectorizer by detecting the identity itself but with
the current structure of vect_transform_slp_perm_load this
On 04/12/15 17:46, Ramana Radhakrishnan wrote:
On 04/12/15 16:04, Richard Biener wrote:
On December 4, 2015 4:32:33 PM GMT+01:00, Alan Lawrence
wrote:
On 27/11/15 08:30, Richard Biener wrote:
This is part 1 of a fix for PR68533 which shows that some targets
cannot can_vec_perm_p on an
Since r229889, we now have tests that pass only with ISL 0.15. Although ISL 0.15
is not a requirement, it seems we should make it easy to build the compiler that
way.
Other opinions?
Thanks,
Alan
contrib/ChangeLog:
* download_prerequisites: Update ISL version to 0.15.
---
contrib/downl
On 07/12/15 11:54, Markus Trippelsdorf wrote:
On 2015.12.07 at 11:52 +, Alan Lawrence wrote:
Since r229889, we now have tests that pass only with ISL 0.15. Although ISL 0.15
is not a requirement, it seems we should make it easy to build the compiler that
way.
This is already fixed by
On 13/11/15 14:52, Jonathan Wakely wrote:
That patch was wrong, the new macros in include/bits/c++config used
"CSTDIO" instead of "STDIO" so it caused several tests to go from
PASS to UNSUPPORTED, oops!
This is the correct version, tested again more carefully, on
powerpc64le-linux and powerpc-ai
Runs of the guality testsuite can sometimes end up with gcc.log containing
malformed lines like:
A debugging session is active.PASS: gcc.dg/guality/pr36728-1.c -O2 line 18
arg4 == 4
A debugging session is active.PASS: gcc.dg/guality/restrict.c -O2 line 30
type:ip == int *
Inferior
Following patch replaces the current "temporary inline assembler" implementation
of vget_high. So this patch adds a test first. We don't have any test coverage
of vget_low, either, so add that too.
Passing on aarch64-none-elf and aarch64_be-none-elf.
diff --git a/gcc/testsuite/gcc.target/aarch6
This patch replaces the current inline assembler for the vget_high intrinsics in
arm_neon.h with a sequence of other calls, in a similar fashion to vget_low.
Unlike the assembler, these are all transparent to the front-end, so should
enable better optimization through the mid-end.
Tested check
(It is no more expensive.)
gcc/ChangeLog:
* config/aarch64/aarch64.md (subdi3, adddi3_aarch64): Don't penalize
SIMD reg variant.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index f8eb305140e7b0aed006b33f1724a90939e48316..0a8ca4bcc7941f912c8d42200b332
This patch adds SIMD register variants for and, ior, xor and not - similarly to
add/sub, the H/W supports it, and it'll be more efficient if the values are
there already, e.g. if passed as [u]int64x1_t parameters.
gcc/ChangeLog:
* config/aarch64/aarch64.md (3, one_cmpl2):
Add S
Following the change to make arm_neon.h's (u?)int64x1_t types into vectors,
these types are now passed in the SIMD registers rather than general purpose
registers, which often results in poor quality code in functions taking or
returning these types. Often values are moved from vector registers
[When I wrote that xor was broken on GPRs and this fixes it, I meant
xor_one_cmpl rather than xor, sorry!]
The pattern for xor_one_cmpl never matched, due to the action of
combine_simplify_rtx; hence, separate this pattern out from that for ORN/BIC.
ORN/BIC have equivalent SIMD-reg variants,
...patch attached...
Alan Lawrence wrote:
[When I wrote that xor was broken on GPRs and this fixes it, I meant
xor_one_cmpl rather than xor, sorry!]
The pattern for xor_one_cmpl never matched, due to the action of
combine_simplify_rtx; hence, separate this pattern out from that for ORN/BIC
an
Kugan wrote:
On 13/08/14 00:55, Alan Lawrence wrote:
...patch attached...
Alan Lawrence wrote:
[When I wrote that xor was broken on GPRs and this fixes it, I meant
xor_one_cmpl rather than xor, sorry!]
The pattern for xor_one_cmpl never matched, due to the action of
combine_simplify_rtx; he
SIMD registers, the '!' still doesn't express
that; and leaving it in affects code-generation on all cores. And it is
inconsistent with other instructions.
--Alan
pins...@gmail.com wrote:
On Aug 12, 2014, at 7:40 AM, Alan Lawrence wrote:
(It is no more expensive.)
Yes on som
). If none of you folk are
able to build+test the patch (below) for Ada on Alpha: is this really reason for
us to want to hold this up?
--Alan
Alan Lawrence wrote:
...as I've not managed to build such a gcc. If so, is there any chance you could
please test check-ada with the followin
Vector comparisons are sometimes generated with needless 'not' instructions, and
'cmtst' is generally not output at all. This patch makes
gen_aarch64_vcond_internal more intelligent with regard to swapping the operands
to both the comparison and the conditional move, such that not is avoided whe
The vector compare intrinsics (vc[gl][et]z, vceqz, vtst) were written using
__builtin functions as (IIUC) at the time gcc vector extensions did not support
comparison ops across both C and C++ frontends. These have since been updated.
Following the first patch, we now get equal/better code gene
This patch adds the missing vrbit_p8 and vrbitq_p8 intrinsics to arm_neon.h, and
implements all the vrbit(q?)_[psu]8 intrinsics using a new builtin, rather than
the previous temporary asm. Also adds a testcase checking (a) execution results
and (b) that we output rbit vXX.8b,vYY.8b or correspond
This patch just replaces the varargs with a builtin_simd_arg*. The use of
varargs seems to make stepping into, and breakpointing, aarch64_simd_expand_args
difficult, and this adds typesafety and (I argue!) reduces complexity.
Tested check-gcc on aarch64-none-elf.
gcc/ChangeLog:
* conf
The SIMD-register variant is miscategorized as "alu_reg" despite not using any
ALU registers, and should be "neon_add" for e.g. scheduling.
Tested with check-gcc and check-g++ on aarch64-none-elf and aarch64_be-none-elf.
gcc/ChangeLog:
* config/aarch64/aarch64.md (adddi3_aarch64): set
The only reference is in a comment.
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers):
Remove qualifier_const_pointer, update comment.diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 5217f4a5f39224dbf
Thanks to Arnaud for confirming that Adacore does not have interest in the
Ada/Alpha combination
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01832.html).
As per below, I've tested check-ada on x86_64-none-linux-gnu without problems.
Can I say, "ping"? :)
Cheers, Alan
Alan
Completely as an aside: this makes me wonder, whether having and using a similar
macro _inside_ gcc, i.e. for targets to specify the ordering of elements within
a vector independently of BYTES_BIG_ENDIAN, might be a good thing?
--Alan
Bill Schmidt wrote:
Hi,
This adds a macro to indicate the
eimplement.
--Alan
Marcus Shawcroft wrote:
On 12 August 2014 11:12, Alan Lawrence wrote:
This patch replaces the current inline assembler for the vget_high
intrinsics in arm_neon.h with a sequence of other calls, in a similar
fashion to vget_low. Unlike the assembler, these are all transparent to
Pushed r214946. (In the meantime the erroneous alu_reg had been changed to
alu_sreg by r212750 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00679.html .)
Marcus Shawcroft wrote:
On 20 August 2014 10:25, Alan Lawrence wrote:
The SIMD-register variant is miscategorized as "alu_reg&quo
suite running.
I repeat, this is source-code-compatibility breaking, but not ABI breaking; if
it causes you any problems, it'll be the 4.9.x compiler shouting at you ;).
Ok assuming no regressions?
--Alan
Marcus Shawcroft wrote:
On 24 July 2014 11:18, Alan Lawrence wrote:
The ACLE spe
This adds a test of all the variants of vld2, vld2q, vld3, vld3q, vld4, and
vld4q. These all use typexNxM structs and the OI/CI/XImode mechanism, so the
test cross-checks this against plain ol' vst1(q?).
Cross-tested on aarch64-none-elf (passing), also on aarch64_be-none-elf
(https://gcc.gnu.o
The existing vld1/vst1_1.c test in gcc.target/aarch64 covers only vld1_s8 and
vld1q_s16. This extends it to cover all int/float variants via token-pasting.
Passing on aarch64-none-elf and aarch64_be-none-elf.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/vld1-vst1_1.c: Rewrite to test
This adds a test of the vld2_dup, vld2q_dup, vld3_dup, vld3q_dup, vld4_dup and
vld4q_dup instrinsics.
Passing on aarch64-none-elf and aarch64_be-none-elf.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/vldN_dup_1.c: New test.diff --git a/gcc/testsuite/gcc.target/aarch64/vldN_dup_1.c b/g
At present there is no test coverage of the vld2_lane, vld2q_lane, vld3_lane,
vld3q_lane, vld4_lane, vld4q_lane intrinsics. So this adds a test using the vld1
and vst1 intrinsics.
Passing on aarch64-none-elf.
Failing on aarch64_be-none-elf; I believe because the intrinsic is [modifying
the] w
This adds a test of all the variants of vst2, vst2q, vst3, vst3q, vst4, and
vst4q. These all use typexNxM structs and the OI/CI/XImode mechanism, so the
test cross-checks this against plain ol' vld1(q?).
Cross-tested on aarch64-none-elf (passing), also on aarch64_be-none-elf (failing
as per h
(No regressions in check-gcc or check-g++ on aarch64-none-elf.)
--Alan
Alan Lawrence wrote:
Some manual editing of patch required due to e.g. int64x1 changes present on
trunk but not on the 4.9 branch; new patch attached.
I've done a quick smoke test of aarch64.exp+simd.exp (check-gcc
Pushed as r215015.
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.c
(aarch64_types_cmtst_qualifiers, TYPES_TST): Remove as unused.
-
Index: gcc/config/aarch64/aarch64-builtins.c
===
--- gcc/config/aarch64/aar
rgets aarch64-none-elf and aarch64_be-none-elf, but
FAIL for aarch64-none-linux-gnu.
It seems this is not what you saw in your own validations?
Christophe.
On 2 September 2014 17:17, Marcus Shawcroft wrote:
On 19 August 2014 11:44, Alan Lawrence wrote:
gcc/ChangeLog:
* config/aa
The sshr_n_64 intrinsics allow performing a signed shift right by 64 places. The
standard ashrdi3 pattern masks the sign amount with 63, so cannot be used.
However, such a shift fills the result by the sign bit, which is identical to
shifting right by 63. This patch just simplifies the code to s
Patch attached.
Alan Lawrence wrote:
The sshr_n_64 intrinsics allow performing a signed shift right by 64 places. The
standard ashrdi3 pattern masks the sign amount with 63, so cannot be used.
However, such a shift fills the result by the sign bit, which is identical to
shifting right by 63
const0_rtx.
(aarch64_ushr_simddi): Delete.
* config/aarch64/aarch64.md (enum unspec): Delete UNSPEC_USHR64.
Alan Lawrence wrote:
The sshr_n_64 intrinsics allow performing a signed shift right by 64 places. The
standard ashrdi3 pattern masks the sign amount with 63, so cannot be used
This adds a test thath checks the result of a vset_lane intrinsic is identical
to the input apart from one value being changed.
Test checks only one index per vset_lane_xxx in a somewhat adhoc fashion as the
index has to be a compile-time immediate and I felt that doing a loop using
macros did
mbler with __aarch64_vset_lane_any.
OK for trunk?
Alan Lawrence wrote:
This adds a test thath checks the result of a vset_lane intrinsic is identical
to the input apart from one value being changed.
Test checks only one index per vset_lane_xxx in a somewhat adhoc fashion as the
index has to be a compile-time imm
interpret_s32_f64, vreinterpret_u8_f64, vreinterpret_u16_f64,
vreinterpret_u32_f64): Use cast.
* config/aarch64/iterators.md (VD_RE): Delete.commit 126c5b92eea2850367f005ebe89f86c5b8b4e4f9
Author: Alan Lawrence
Date: Wed Aug 6 14:23:00 2014 +0100
float64x1 reinterprets can now
g all backends to the new _scal_ optab (and
removing the vector optab). Certainly I'd like to replace vec_shr/l with
vec_perm_expr too, but I'm conscious that the end of stage 1 is approaching!
--Alan
Richard Biener wrote:
On Thu, Sep 18, 2014 at 1:41 PM, Alan Lawrence wrote:
The end
or
assistance: how can one add a vec_extract, to produce a scalar result, to the
end of each reduc_ optab ?
--Alan
Richard Biener wrote:
> > On Mon, Oct 6, 2014 at 7:30 PM, Alan Lawrence wrote:
>> >> Ok, so unless there are objections, I plan to commit patches 1, 2, 4, 5
Sorry, somehow I missed this email. Yes, that appears to have fixed it!
Thank you very much,
Alan
Trevor Saunders wrote:
On Tue, Sep 09, 2014 at 03:37:26PM +0100, Alan Lawrence wrote:
Following this, we're seeing ICEs in tests in gcc.dg/pch.exp and g++.dg/pch.exp,
with cross-builds (host
target ILP32
--Alan
From: Rainer Orth [r...@cebitec.uni-bielefeld.de]
Sent: 23 October 2014 14:10
To: Andreas Schwab
Cc: Alan Lawrence; Jeff Law; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c
An
Rainer Orth wrote:
However, as a quick first step, does adding the ilp32 / lp64 (and keeping
the architectures list for now) solve the immediate problem? Patch
attached, OK for trunk?
No, as I said this is wrong for biarch targets like sparc and i386.
When you say no this does not solve the
, so might changing the meaning of the optab, and
its signature, with the existing name, so am open to suggestions?
Cheers, Alancommit 9819291c17610dcdcca19a3d9ea3a4260df0577e
Author: Alan Lawrence
Date: Thu Aug 21 13:05:43 2014 +0100
Temporarily remove gimple_fold
diff --git a/gcc/con
...
(reduc_plus_scal_*): ...this; reduce to temp and extract scalar result.commit 22e60bd46f2a591f5357a543d76b19ed89f401ed
Author: Alan Lawrence
Date: Thu Aug 28 16:12:24 2014 +0100
ARM reduc_plus_scal, V_elem not V_ext, rm old reduc_[us]plus, emit the extract!
diff --git a/gcc/config/arm/neon.md
result.commit 537c31561933f8054a2289198f35b19cf5c4196e
Author: Alan Lawrence
Date: Thu Aug 28 16:49:24 2014 +0100
ARM reduc_[us](min|max)_scal, V_elem not V_ext, rm old non-_scal version.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index d13fe5d..19e1ba0 100644
--- a/gcc/config/arm
, reduc_plus_scal_v4sf): ...these, adding
gen_vec_extract for scalar result.commit 80b0d10a78b2f3e86325f373e99e9cf71e42e622
Author: Alan Lawrence
Date: Tue Oct 7 13:25:08 2014 +0100
i386
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4c4a6eb..670a5f5 100644
--- a
This is an attempt to migrate IA64 to the newer optabs, however, I found none of
the tests in gcc.dg/vect seemed to touch any of the affected patternsso this
is only really tested by building a stage-1 compiler.
gcc/ChangeLog:
* config/ia64/vect.md (reduc_splus_v2sf): Rename to...
This migrates the reduction patterns in altivec.md and vector.md to the new
names. I've not touched paired.md as I wasn't really sure how to fix that (how
do I vec_extractv2sf ?), moreover the testing I did didn't seem to exercise any
of those patterns (iow: I'm not sure what would be an appropr
Ooops, attached.commit e48d59399722ce8316d4b1b4f28b40d87b1193fa
Author: Alan Lawrence
Date: Tue Oct 7 15:28:47 2014 +0100
PowerPC v2 (but not paired.md)
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 02ea142..92bb5d0 100644
--- a/gcc/config/rs6000
Ooops, attached.commit 56296417b9f6795e541b1101dce6e6ac1789de9a
Author: Alan Lawrence
Date: Wed Oct 8 15:58:27 2014 +0100
IA64 (?!)
diff --git a/gcc/config/ia64/vect.md b/gcc/config/ia64/vect.md
index e3ce292..45f4156 100644
--- a/gcc/config/ia64/vect.md
+++ b/gcc/config/ia64/vect.md
(In answer to your point about adding an effective-target in target-supports.exp
- yes, could do that, but it's difficult to come up with a good characterization
of what the criteria is, and I don't see it'd generalize to any other tests at
all :()
--Alan
Rainer Orth wrote:
re is just a one-line
conflict with a change to a comment from the previous patch (which I'm skipping)...
Cheers, Alan
Richard Biener wrote:
On Thu, Sep 18, 2014 at 2:35 PM, Alan Lawrence wrote:
The VEC_LSHIFT_EXPR tree code, and the corresponding vec_shl_optab, seem to
have been
linaro.org/build/cross-validation/gcc/211058/report-build-info.html
Can you check?
Thanks,
Christophe.
On 19 May 2014 14:53, Marcus Shawcroft wrote:
On 23 April 2014 21:22, Alan Lawrence wrote:
2014-03-27 Alan Lawrence
* config/aarch64/aarch64-builtins.c
(aarch64_types_binopv_
Ok, this fixes it. We'll output an ext...#0, which is little more than a MOV,
but that seems appropriate in the circumstance.
Regression tested check-gcc and check-g++ on aarch64-none-elf and
aarch64_be-none-elf.
Ok for trunk?
--Alan
Alan Lawrence wrote:
Yes, reproduced. Seems the mi
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ext): Allow+handle location==0.
?
--Alan
Marcus Shawcroft wrote:
On 3 June 2014 11:21, Alan Lawrence wrote:
Ok, this fixes it. We'll output an ext...#0, which is little more than a
MOV,
but that seems appropriate i
he call to aarch64_evpc_rev ahead of the call to
aarch64_evpc_ext in aarch64_expand_vec_perm_const_1. The actual patch I
committed is attached.
Cheers, Alan
Marcus Shawcroft wrote:
On 15 May 2014 16:52, Alan Lawrence wrote:
2014-05-15 Alan Lawrence
* config/aarch64/aarch64-simd.md
(a
Pushed as r211177.
Thanks, Alan
Marcus Shawcroft wrote:
On 3 June 2014 12:19, Alan Lawrence wrote:
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ext): Allow+handle
location==0.
?
Allow and handle location == 0.
Otherwise OK
/Marcus
Baking on trunk as of rev 211369.
--Alan
Ramana Radhakrishnan wrote:
On Wed, May 14, 2014 at 2:52 PM, Alan Lawrence wrote:
Hi,
Due to differences in how the ARM C Language Extensions and gcc's vector
extensions deal with indices within vectors, the __builtin_shuffle masks
used to impl
hort, int16x1_t, s16)
-
-TEST (char, int8x1_t, s8)
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 211634)
+++ gcc/testsuite/ChangeLog (revision 211635)
@@ -1,3 +1,7 @@
+2014-06-13 Alan Lawrence
+
+ * gcc.dg/v
comment.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c9ab54f..80fa36b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-06-16 Alan Lawrence
+
+ Backport r210219 from mainline
+
+ 2014-05-08 Ramana Radhakrishnan
+
+ * config/arm/arm_neon.h: Update comment.
+ *
According to the ARM C Language Extensions the 64x1 types should all be passed
in the SIMD registers rather than GPRs, and should not be assignment-compatible
with [u]int64_t / float64_t (as they are at present). These two patches (first
for float64x1_t, second for [u]int64x1_t) make these types
ously equivalent) type signature; and add some new
ABI tests.
gcc/ChangeLog:
2014-06-19 Alan Lawrence
* config/aarch64/aarch64.c (aarch64_simd_mangle_map): Add entry for
V1DFmode.
* config/aarch64/aarch64-builtins.c (aarch64_simd_builtin_type_mode):
add V1D
This backports straightforwardly; no regressions on arm-none-eabi or
armeb-none-eabi, and FAIL->PASS of the new ZIP, UZP, and TRN execution tests
from r209908, r209947 and r210422 (running locally).
--Alandiff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 4d945ce..a930e05
As for 4.8, I'm intending to backport the ZIP/UZP/TRN fix for ARM big-endian in
r211369 of mainline. That patches arm_neon.h, so again we need to remove the
OCAML code by which that file is autogenerated...ok?
--Alancommit e83cb5fff3687316ff391e9e7a8c65df2d35c880
Author: Alan Lawrence
Scan-assembler test was running with "dg-do assemble" and not generating any
assembler to scan.
Tested on aarch64-none-elf and aarch64_be-none-elf; 40 * UNRESOLVED->PASS tests
in singleton_intrinsics_1.c
Patch (below) committed as r211934.
--Alan
--
Index: gcc/testsuite/gcc.target/
: Likewise.
* gcc.target/aarch64/simd/ext_u64_1.c: Likewise.
* gcc.target/aarch64/simd/ext_s64.x: Remove.
* gcc.target/aarch64/simd/ext_u64.x: Remove.
--Alan
James Greenhalgh wrote:
On Thu, Jun 19, 2014 at 01:30:32PM +0100, Alan Lawrence wrote:
diff --git a/gcc/testsuite
This one seems to have slipped under the radar. I've just rebased and run the
regression tests on aarch64_be-none-elf, with no issues; ping?
(patch applied straightforwardly, but rebased version below)
--Alan
Alan Lawrence wrote:
At present vec_perm with non-const indices is not handl
combine.c includes a check which prevents
(ashiftrt (xor A C2) C1)
from being commuted to
(xor (ashiftrt A C1) (ashiftrt C2 C1))
for constants C1, C2 if C2 has its sign bit set.
Specifically, this prevents (ashiftrt (not A) C1) from being commuted to
(not (ashiftrt A C1))
because the former
Moving into own thread from
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01895.html
This fixes the compilation failures of gcc.target/arm/simd/vexts64_1.c and
gcc.target/arm/simd/vextu64_1.c that I introduced in r by unsharing the test
body on AArch64. (As [u]int64x1_t are vector types on AAr
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf,
arm-none-eabi, x86_64-unknown-linux-gnu:
NA->PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20)
NA->PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors)
gcc/ChangeLog:
* config/aarch64/aar
101 - 200 of 583 matches
Mail list logo
