On 10/03/16 16:18, Dominique d'Humières wrote:
> The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It
> needs some regexp
Indeed, confirmed on ARM, sorry for not spotting this earlier.
I believe the variable, if there is one, should always be called 'j', as it is
in the sour
On 04/03/16 17:24, Alan Lawrence wrote:
On 26/02/16 14:52, James Greenhalgh wrote:
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
Rewrite, looking one level down for records and arrays.
---
gcc/config/aarch64/aarch64.c | 31
In this PR, a packed structure containing bitfields, loses part of its
constant-pool initialization in SRA.
A fuller explanation is on the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013#c11. In short we need to
treat constant-pool entries, like function parameters, as both come
'pre-initi
On 07/03/16 11:02, Alan Lawrence wrote:
On 04/03/16 13:27, Richard Biener wrote:
I think to make it work with LTO you need to mark it 'Optimization'.
Also it's about
arrays so maybe
'Assume common declarations may be overridden with ones with a larger
trailing array'
he same wording in invoke.texi, unless you think there
is more to add.
On 04/03/16 13:33, Jakub Jelinek wrote:
> Also, isn't the *.opt description line supposed to end with a full stop?
Ah, yes, thanks.
Is this version OK for trunk?
gcc/ChangeLog:
DATE Alan Lawrence
Jaku
On 26/02/16 14:52, James Greenhalgh wrote:
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
Rewrite, looking one level down for records and arrays.
---
gcc/config/aarch64/aarch64.c | 31 ---
1 file changed, 16 inserti
On 25/02/16 18:00, Alan Lawrence wrote:
On 22/02/16 12:03, Jakub Jelinek wrote:
(f) A global command-line option, which we check alongside DECL_COMMON and
further tests (basically, we want only DECL_COMMON decls that either have
ARRAY_TYPE, or some other aggregate type with flexible array
that this be combined with some flag fiddling and warnings in the Fortran
front-end; this patch doesn't do that, as I'm not very familiar with the
frontends, but that can follow in a separate patch. (Thomas?)
OK for trunk?
Cheers, Alan
gcc/ChangeLog:
DATE Alan Lawrence
On 20/02/16 09:29, Ilya Enkovich wrote:
2016-02-19 20:36 GMT+03:00 Alan Lawrence :
Mostly this is fairly straightforward, relatively little midend code is
required, and the backend cleans up quite a bit. However, I get stuck on the
case of singleton vectors (64x1). No surprises there, then
On 22/02/16 12:03, Jakub Jelinek wrote:
(f) A global command-line option, which we check alongside DECL_COMMON and
further tests (basically, we want only DECL_COMMON decls that either have
ARRAY_TYPE, or some other aggregate type with flexible array member or some
other trailing array in the str
On 22/01/16 17:16, Alan Lawrence wrote:
On 21/01/16 17:23, Alan Lawrence wrote:
On 18/01/16 17:10, Eric Botcazou wrote:
Could you post the list of files that differ? How do they differ exactly?
Hmmm. Well, I definitely had this failing to bootstrap once. I repeated that, to
try to
On 19/02/16 17:52, Jakub Jelinek wrote:
On Fri, Feb 19, 2016 at 05:42:34PM +, Alan Lawrence wrote:
This relates to FORTRAN code where different modules give different sizes to the
same array in a COMMON block (contrary to the fortran language specification).
SPEC have refused to patch the
This relates to FORTRAN code where different modules give different sizes to the
same array in a COMMON block (contrary to the fortran language specification).
SPEC have refused to patch the source code
(https://www.spec.org/cpu2006/Docs/faq.html#Run.05).
Hence, this patch provides a Fortran-speci
On 17/11/15 11:49, Ilya Enkovich wrote:
Hi,
Default hook for get_mask_mode is supposed to return integer vector modes.
This means it should reject calar modes returned by mode_for_vector.
Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on
aarch64-unknown-linux-gnu. OK for
On 04/02/16 09:53, Dominik Vogt wrote:
On Wed, Feb 03, 2016 at 11:41:02AM +, Alan Lawrence wrote:
On 26/01/16 12:23, Dominik Vogt wrote:
On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64
On 26/01/16 12:23, Dominik Vogt wrote:
On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
How did you test this on s390? For me, the
On 21/01/16 17:23, Alan Lawrence wrote:
> On 18/01/16 17:10, Eric Botcazou wrote:
>>
>> Could you post the list of files that differ? How do they differ exactly?
>
> Hmmm. Well, I definitely had this failing to bootstrap once. I repeated that,
> to
> try to identify e
On 20/01/16 21:10, Christophe Lyon wrote:
On 19 January 2016 at 15:51, Alan Lawrence wrote:
On 19/01/16 11:15, Christophe Lyon wrote:
For neon_vdupn, I chose to implement neon_vdup_nv4hf and
neon_vdup_nv8hf instead of updating the VX iterator because I thought
it was not desirable to impact
Since r230292, these tests in gcc.dg/vect have been failing on ARM, AArch64,
and x86_64 with -march=haswell (among others - when prefer_avx128 is true):
vect-outer-1-big-array.c scan-tree-dump-times vect "grouped access in outer
loop" 2
vect-outer-1.c scan-tree-dump-times vect "grouped access in
This is a scan-tree-dump failure in vect-over-widen-3-big-array.c, that occurs
only on ARM - the only platform to have vect_widen_shift.
Tested on arm-none-eabi (armv8-crypto-neon-fp, plus a non-neon variant), also
aarch64 (token platform without vect_widen_shift).
gcc/testsuite/ChangeLog:
On 18/01/16 17:10, Eric Botcazou wrote:
Similarly to ARM, I note that Ada is affected. Indeed, with a gcc 4.9 host
compiler, I saw a bootstrap miscompare iff including Ada; however, I was
able to bootstrap Ada successfully, if I first built a GCC including this
patch with --disable-bootstrap, and
On 19/01/16 11:15, Christophe Lyon wrote:
For neon_vdupn, I chose to implement neon_vdup_nv4hf and
neon_vdup_nv8hf instead of updating the VX iterator because I thought
it was not desirable to impact neon_vrev32.
Well, the same instruction will suffice for vrev32'ing vectors of HF just as
well
On 19/01/16 09:46, Christophe Lyon wrote:
On 19 January 2016 at 04:05, H.J. Lu wrote:
On Thu, Dec 24, 2015 at 3:55 AM, Alan Lawrence wrote:
This version changes the test cases to fix failures on some platforms, by
rewriting the initializers so that they aren't pushed out to the constant
Thanks for working on this, Christophe, and sorry I missed the PR. You got
further in fixing more things than I did though :). A couple of comments:
> For the vec_set_internal and neon_vld1_dup patterns, I
> switched to an existing iterator which already had the needed
> V4HF/V8HF (so I switched t
This cleans up the neon_reinterpret code on ARM in a similar way to AArch64.
Rather than a builtin backing onto an expander that emits a mov insn, we can
just use a cast, because GCC defines casts of vector types as keeping the same
bit pattern.
On armeb, this fixes previously-failing test:
gcc.ta
This fixes ICEs on armeb for float16x[48]_t vectors, e.g. in
check_effective_target_arm_neon_fp_16_ok.
At present, without the expander, moving v4hf/v8hf values around is done
via subregs. On armeb, this ICEs because REG_CANNOT_CHANGE_MODE_P. (On arm-*,
moving via two subregs is less efficient tha
Here I've added both tests using the abitest.h framework(which verifies values
are passed in the correct registers as specified by the AAPCS64), and separate
tests which verify that called functions read arguments from the same locations
as they are passed. Hence, each test_align-N.c corresponds to
These parallel the updates to ARM
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00214.html following from Richard
Earnshaw's proposal for updates to the AAPCS and AAPCS64,
https://gcc.gnu.org/ml/gcc/2015-07/msg00040.html .
On AArch64 we do not have the problem of broken profiledbootstrap (as orig
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
Rewrite, looking one level down for records and arrays.
---
gcc/config/aarch64/aarch64.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/gcc/confi
Mon, 2015-12-21 at 15:22 +, Alan Lawrence wrote:
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile
On 15/01/16 10:07, Richard Biener wrote:
On Fri, Jan 15, 2016 at 10:47 AM, Alan Lawrence wrote:
On Thu, Jan 14, 2016 at 12:30 PM, Richard Biener
wrote:
The vuse test is not necessary
+ && (gimple_assign_rhs_code (def) ==
On 24/12/15 11:53, Alan Lawrence wrote:
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64. Prior to SRA handling constant pool decls,
-fdump-tree-esra-details (at -O1 -g) had shown:
:
a = *.LC0;
# DEBUG a$0 => MEM[(int[3] *)&
On Thu, Jan 14, 2016 at 12:30 PM, Richard Biener
wrote:
>
> The vuse test is not necessary
>
>> + && (gimple_assign_rhs_code (def) == SSA_NAME
>> + || is_gimple_min_invariant (gimple_assign_rhs1 (def
>
> and the is_gimple_min_invariant (rhs1) test is not suffici
On 14/01/16 12:22, Richard Biener wrote:
On Thu, Jan 14, 2016 at 11:26 AM, Alan Lawrence wrote:
If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no
uses of the old reduc_* optabs remaining
On 07/01/16 12:47, Alan Lawrence wrote:
Here's an updated version, also covering the min/max patterns I missed before.
I've now managed to do some testing with a stage 1 compiler, by compiling all
tests in gcc.dg/vect at -O2 -ftree-vectorize -mips3d -march=mips64r2 -mabi=n32
$x -
(Previous message: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02159.html)
On Sat, Dec 26, 2015 at 18:58 PM, Richard Biener
wrote:
>> I'm not sure whether adding a pass_copy_prop is the right thing here, but
>> since
>> loop-header-copying can create such opportunities, it seems good to take
If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no
uses of the old reduc_* optabs remaining. This patch removes those optabs and
the migration path.
Bootstrapped + check-gcc + check-g++ on x86
This was an attempt to make more of the vect testsuite compilable with a stage-1
compiler, i.e. without standard header files like stdlib.h, to ease looking for
differences in assembly output. (It is still necessary to comment out most of
tree-vect.h to do this, but at least such temporary/local ch
On 11/01/16 10:28, Marcus Shawcroft wrote:
On 11 January 2016 at 08:12, Bilyan Borisov wrote:
2015-XX-XX Bilyan Borisov
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): New
macro
definition.
gcc/testsuite/
2015-XX-XX Bilyan Borisov
* gcc.target/a
aarch64
(various new scan-tree-dump tests all passing, and PASS->FAIL for O3-pr36098.c).
gcc/ChangeLog:
2016-01-XX Alan Lawrence
Richard Biener
* tree-vect-slp.c (vect_analyze_slp_instance): Cancel permuted SLP
instances that can be handled via vect_load_lanes.
g
There are only a couple of uses of the old reduction optabs remaining
(the optabs producing a vector with only one element set). This migrates the
uses in gcc.target/rs6000/paired.md.
In the absence of a vec_extract pattern, I generate two subreg moves, the same
as usually produced by the midend w
Here's an updated version, also covering the min/max patterns I missed before.
I've now managed to do some testing with a stage 1 compiler, by compiling all
tests in gcc.dg/vect at -O2 -ftree-vectorize -mips3d -march=mips64r2 -mabi=n32
$x -ffast-math -ffinite-math-only.
There were no changes in wh
On 05/01/16 07:29, Richard Biener wrote:
On January 4, 2016 8:08:17 PM GMT+01:00, Jeff Law wrote:
On 12/21/2015 06:13 AM, Alan Lawrence wrote:
This is a respin of patches
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03266.html and
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03267.html
Ping.
--Alan
On 10/12/15 10:31, Alan Lawrence wrote:
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
On 24/12/15 11:53, Alan Lawrence wrote:
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64.
[snip]
This also fixes a bunch of other guality tests on AArch64 that were failing
prior to the patch series, and another bunch on PowerPC64 (bige
On 24/12/15 19:59, Mike Stump wrote:
On Dec 22, 2015, at 8:00 AM, Alan Lawrence wrote:
On 21/12/15 15:33, Bill Schmidt wrote:
Not on a stage1 compiler - check_p8vector_hw_available itself requires being
able to run executables - I'll check on gcc112. However, both look like they'
This version changes the test cases to fix failures on some platforms, by
rewriting the initializers so that they aren't pushed out to the constant pool.
gcc/ChangeLog:
* tree-ssa-scopedtables.c (avail_expr_hash): Hash MEM_REF and ARRAY_REF
using get_ref_base_and_extent.
(
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64. Prior to SRA handling constant pool decls,
-fdump-tree-esra-details (at -O1 -g) had shown:
:
a = *.LC0;
# DEBUG a$0 => MEM[(int[3] *)&*.LC0]
a$4_3 = MEM[(int[3] *)&*.LC0 + 4B];
# DEBUG a$4
On 22/12/15 16:05, Bill Schmidt wrote:
On Tue, 2015-12-22 at 15:54 +, Alan Lawrence wrote:
On 21/12/15 13:13, Alan Lawrence wrote:
This is a respin of previous patch series:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03271.html
Minus three of the smaller patches having already been
On 21/12/15 15:33, Bill Schmidt wrote:
Not on a stage1 compiler - check_p8vector_hw_available itself requires being
able to run executables - I'll check on gcc112. However, both look like they're
really about the host (ability to execute an asm instruction), not the target
(/ability for gcc to o
On 21/12/15 13:13, Alan Lawrence wrote:
This is a respin of previous patch series:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03271.html
Minus three of the smaller patches having already been committed; with the
updated version of the main patch to SRA; and the patches to DOM reworked
to
On 21/12/15 11:58, Bilyan Borisov wrote:
This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsincs. It also
implements the __ARM_FEATURE_NUMERIC_MAXMIN macro, which is defined when
__ARM_ARCH >= 8, and which enables the intrinsincs.
Tested on arm-none-eabi, armeb-none-eabi, arm-none-linux-
On 16/12/15 09:31, Kyrill Tkachov wrote:
Hi David,
On 16/12/15 08:53, David Sherwood wrote:
Hi,
Here is the last patch of the fmin/fmax change, which adds the optabs
to the arm backend.
Tested:
arm-none-eabi: no regressions
Good to go?
David Sherwood.
ChangeLog:
2015-12-08 David Sherwood
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile without SIMD support), and
the test fails; hence, I've
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile without SIMD support), and
the test fails; hence, I've
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
On alpha, tree-optimized is:
MEM[(int[8] *)&a] = { 0, 1 };
MEM[(int[8] *)&a + 8B] = { 2, 3 };
MEM[(int[8] *)&a + 16B] = { 4, 5 };
MEM[(int[8] *)
This fixes the missed vectorization of gcc.dg/vect/pr65947-2.c following the
previous patch, by cleaning up:
i_49 = 1;
...
goto ;
:
: <--- LOOP HEADER
# i_53 = PHI
into:
:
# i_53 = PHI
Allowing scalar evolution and vectorization to proceed.
A similar sequence of partial pee
This is the same as the version conditionally approved near the end of stage 1
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01948.html, plus the
requested comment and a couple of testcases for platforms where the constants
are pushed into the constant pool. (I didn't commit this at the time becaus
This is a respin of patches
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03266.html and
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03267.html, which were
"too quickly" approved before concerns with efficiency were pointed out.
I tried to change the hashing just in tree-ssa-dom.c using C++ subc
This is a respin of previous patch series:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03271.html
Minus three of the smaller patches having already been committed; with the
updated version of the main patch to SRA; and the patches to DOM reworked
to avoid constructing gimple stmt's.
IMHO this fe
On 17/12/15 10:46, Richard Biener wrote:
On Thu, 17 Dec 2015, Alan Lawrence wrote:
On 16/12/15 15:01, Richard Biener wrote:
The following patch adds a heuristic to prefer store/load-lanes
over SLP when vectorizing. Compared to the variant attached to
the PR I made the STMT_VINFO_STRIDED_P
On 16/12/15 15:01, Richard Biener wrote:
The following patch adds a heuristic to prefer store/load-lanes
over SLP when vectorizing. Compared to the variant attached to
the PR I made the STMT_VINFO_STRIDED_P behavior explicit (matching
what you've tested).
Not sure I follow this. Compared to t
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
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
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
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 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
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 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 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 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 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 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 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
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 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(/
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 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 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
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
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/
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
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
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 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
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 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 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 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
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
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
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
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 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 06/11/15 16:29, Richard Biener wrote:
>>> 2) You should be able to use fold_ctor_reference directly (in place
>> of
>>> all your code
>>> in case offset and size are readily available - don't remember
>> exactly how
>>> complete scalarization "walks" elements). Alternatively use
>>> fold_const_
On 10/11/15 16:39, Alan Lawrence wrote:
Since r229878, I've been seeing
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable
(both previously passing) on aarch64-none-elf, aarch64_be-none-elf, and
aarch64-none-
On 04/11/15 14:26, Ramana Radhakrishnan wrote:
True and I've just been reading more of the backend - We could now start using
blocks for constant pools as well. So let's do that.
How does something like this look ?
Tested on aarch64-none-elf - no regressions.
2015-11-04 Ramana Radhakrishnan
On 05/11/15 05:08, Alexandre Oliva wrote:
[PR67753] fix copy of PARALLEL entry_parm to CONCAT target_reg
for gcc/ChangeLog
PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Avoid allocating a
stack slot if we don't have a
On 06/11/15 12:55, Richard Biener wrote:
>
>> + /* GROUP_GAP of the first group now has to skip over the second group
>> too. */
>> + GROUP_GAP (first_vinfo) += group2_size;
>
> Please add a MSG_NOTE debug printf stating that we split the group and
> at which element.
Done.
> I think you want
On 04/11/15 13:13, Jakub Jelinek wrote:
On Mon, Jul 06, 2015 at 05:38:35PM +0100, Alan Lawrence wrote:
Trying to push these now (svn!), patch 2 is going first.
I realize my second iteration of patch 1/2, dropped the testcases from the
first version. Okay to include those as per
https
1 - 100 of 583 matches
Mail list logo
