Hi all,
we have backported a set of AArch64 costs model related revisions in
the linaro/gcc-4_9-branch at r211843. The backported revisions are:
210493 : [AArch64 costs 1/18] Refactor aarch64_address_costs.
210494 : [AArch64 costs 2/18] Add cost tables for Cortex-A57
210495 : [AArch64 costs
Hi,
we have merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 210799 as r211850.
Thanks
Yvan
Hi all,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 212419 as r212661. We have also backported this set of revisions:
r209794 as r212697 : PR c/60114
r209797 as r212675 : [ARM] Wrap long literals in HOST_WIDE_INT_C in
aarch-common.c
r209858 as r212697 :
Hi all,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 212635 (4.9.1 release) as r212977, and revert the backport of
the revision 211129 (committed as r212685) as r212866.
This will be part of a 2014.07 respinned release.
Thanks,
Yvan
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 216130 as r216256. We have also backported this set of revisions:
r209643 as 215975 : [AArch64] Define TARGET_FLAGS_REGNUM
r211881 as 215975 : PR target/61565
r213035 as 215846 : [AArch64] libitm: Improve
All,
I have created a distribution branch 'linaro/gcc-4_9-branch'. This
branch is already documented on http://gcc.gnu.org/svn.html
for the recall :
The branch will track the equivalent FSF release branch and also
accept backports of patches accepted for trunk which are of interest
to the ARM
Hi,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 209611 as r209634 (to keep a track of the 4.9.0 release) and
up to revision 209633 as r209635.
This will be part of our 2014.04 release.
Thanks,
Yvan
Hi,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 210052 as r210370. We also have backported Ada AArch64
support as r210372 and 2 other upstream contributions as r210373 and
r210376.
This will be part of our 2014.05 release.
Thanks,
Yvan
Hi all,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 211054 as r211495. We have also backported this set of revisions:
r209419 as r211497 : PR rtl-optimization/60663
r209457 as r211496 : TRY_EMPTY_VM_SPACE Change aarch64 ilp32
r209559 as r211498 : [AArch64]
Hi,
we have merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 208264 as r208471.
This will be part of our 2014.03 release.
Yvan
Hi,
as reported in PR62248 there is a typo in gcc/config.gcc where
--with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
config.gcc). Here is the patch to fix it.
Thanks,
Yvan
2014-08-27 Yvan Roux yvan.r...@linaro.org
* config.gcc: Fix fp-armv8 option for arm
On 27 August 2014 11:24, Richard Earnshaw rearn...@arm.com wrote:
On 27/08/14 09:04, Yvan Roux wrote:
Hi,
as reported in PR62248 there is a typo in gcc/config.gcc where
--with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
config.gcc). Here is the patch to fix it.
Thanks
Here is the patch that uses the arm-fpus.def list.
Thanks
Yvan
2014-08-27 Yvan Roux yvan.r...@linaro.org
* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
On 27 August 2014 12:35, Yvan Roux yvan.r...@linaro.org wrote:
On 27 August 2014 11:24, Richard Earnshaw rearn
with the PR in the ChangeLog:
2014-08-27 Yvan Roux yvan.r...@linaro.org
PR other/62248
* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
On 27 August 2014 13:10, Yvan Roux yvan.r...@linaro.org wrote:
Here is the patch that uses the arm-fpus.def list.
Thanks
Committed on trunk at r214573, and I'll backport it on 4.9 branch.
On 27 August 2014 14:26, Richard Earnshaw rearn...@arm.com wrote:
On 27/08/14 12:35, Yvan Roux wrote:
with the PR in the ChangeLog:
2014-08-27 Yvan Roux yvan.r...@linaro.org
PR other/62248
* config.gcc
true seems to be used that way for aarch64*-*-* and arm*-*-* is it
preferable to change it to ; for all occurrences ?
Thanks,
Yvan
On 27 August 2014 18:51, Bernhard Reutner-Fischer rep.dot@gmail.com wrote:
On 27 August 2014 16:22:28 CEST, Yvan Roux yvan.r...@linaro.org wrote:
Committed
On 27 August 2014 19:07, Yvan Roux yvan.r...@linaro.org wrote:
true seems to be used that way for aarch64*-*-* and arm*-*-* is it
preferable to change it to ; for all occurrences ?
sorry for the typo, I meant colon and not semicolon.
Thanks,
Yvan
On 27 August 2014 18:51, Bernhard Reutner
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 214896 as r215060. We have also backported this set of revisions:
r211717 as r214313 : [AArch32] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook
r212927 as r214314 : [AArch32] Enable arm target in
ira-shrinkwrap-prep*
/
2013-02-14 Yvan Roux yvan.r...@linaro.org
* config/aarch64/atomics.md (dmb): Emit release mode barrier.
0001-AArch64-fix-data-memory-barrier-release-mode.patch
Description: Binary data
Oops, I missed that the release semantics is not just store before
store but also load before store, sorry for that :(
Yvan
On 14 February 2013 16:40, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
a call to the builtin __atomic_thread_fence with the memory model
__ATOMIC_RELEASE generates a data
, but there is a couple of regression in the
testsuite I'm looking at on
- gcc.c-torture/execute/ieee/fp-cmp-4l.c
- c-c++-common/torture/complex-sign-mul-minus-one.c
for instance.
Any comments ?
Thanks
Yvan
On 6 July 2013 01:12, Vladimir Makarov vmaka...@redhat.com wrote:
On 13-07-05 8:43 AM, Yvan Roux
Sorry for the previous off-the-list-html-format answer :(
On 30 August 2013 15:18, Richard Earnshaw rearn...@arm.com wrote:
On 30/08/13 14:09, Yvan Roux wrote:
Hi,
here is a request for comments on the 2 attached patches which enable
the build of GCC on ARM with LRA. The patches introduce
:23, Vladimir Makarov vmaka...@redhat.com wrote:
On 13-09-08 2:04 PM, Richard Sandiford wrote:
Yvan Roux yvan.r...@linaro.org writes:
@@ -5786,7 +5796,11 @@ get_index_scale (const struct address_info *info)
info-index_term == XEXP (index, 0))
return INTVAL (XEXP (index, 1
Hi,
here are the modifications, discussed in another thread, needed in
rtlanal.c by ARM targets (AArch32 and AArch64) to build GCC with LRA.
Is it ok for trunk ?
Thanks,
Yvan
2013-09-09 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka...@redhat.com
* rtlanal.c
Thanks for noticing it Richard, I made a refactoring mistake and addr
was supposed to be used instead of x. In fact on AArch64 it occurs
that we don't have stripped rtxes at this step and we have some of the
form below, this if why I added the strip.
(insn 29 27 5 7 (set (mem:SI (plus:DI
Yeah, but that's because strip_address_mutations doesn't consider
SIGN_EXTRACT to be a mutation as things stand. My point was that
I think it should, at least for the special extract-from-lsb case.
It then shouldn't be necessary to handle SIGN_EXTRACT in the other
address-analysis routines.
Endianness in the BYTES_BIG_ENDIAN sense shouldn't be a problem AFAIK.
We just need to worry about BITS_BIG_ENDIAN. For:
({sign,zero}_extract:m X len pos)
pos counts from the lsb if !BITS_BIG_ENDIAN and from the msb if
BITS_BIG_ENDIAN. So I think the condition should be something like:
New attempt, with fixes from Richard's comments (discussed in the other thread).
Thanks,
Yvan
2013-09-09 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka...@redhat.com
* rtlanal.c (strip_address_mutations): Add bitfield operations
handling
bytes. */
loc = XEXP (*loc, 0);
if you think that it doesn't affect too much the readability.
Many Thanks,
Yvan
On 11 September 2013 09:32, Richard Sandiford
rdsandif...@googlemail.com wrote:
Yvan Roux yvan.r...@linaro.org writes:
@@ -5454,6 +5454,16 @@ strip_address_mutations (rtx
Yeah, good point. TBH I prefer it with separate ifs though, because the
three cases are dealing with three different types of rtl (unary, binary
and ternary). But I don't mind much either way.
Ok, it's fine for me too.
The new patch looks good to me, thanks. Just one minor style nit:
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka...@redhat.com
* rtlanal.c (lsb_bitfield_op_p): New predicate for bitfield operations
from the least significant bit
Adding Eric and Steven in the loop as it is RTL related.
Thanks
Yvan
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka
on
this issue.
- Thumb still doesn't bootstrap.
Thanks,
Yvan
On 11 September 2013 20:57, Yvan Roux yvan.r...@linaro.org wrote:
Yeah, good point. TBH I prefer it with separate ifs though, because the
three cases are dealing with three different types of rtl (unary, binary
and ternary). But I
Hi,
this patch fix the scan-assembler pattern of
gcc.target/arm/atomic-comp-swap-release-acquire.c, which didn't
allowed aliases register and failed when enabling LRA where 'ip' is
used in the ldaex instruction.
Thanks,
Yvan
2013-09-24 Yvan Roux yvan.r...@linaro.org
* gcc.target/arm
Ping
On 16 September 2013 10:57, Yvan Roux yvan.r...@linaro.org wrote:
Adding Eric and Steven in the loop as it is RTL related.
Thanks
Yvan
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11
.html
Thanks,
Yvan
2013-09-24 Yvan Roux yvan.r...@linaro.org
* config/aarch64/aarch64.opt (mlra): New option.
* config/aarch64/aarch64.c (aarch64_lra_p): New function.
(TARGET_LRA_P): Define.
aarch64-lra.diff
Description: Binary data
Hi,
Fair enough - we should just fix the test and move on.
Done.
I would suggest in addition a transitional command-line option to switch
between LRA and reload as a temporary measure so that folks can do some more
experimenting for AArch32.
I've a patch which fixes the REG_NOTE issues,
Hi Eric,
Thanks for the review.
+/* Return true if X is a sign_extract or zero_extract from the least
+ significant bit. */
+
+static bool
+lsb_bitfield_op_p (rtx x)
+{
+ if (GET_RTX_CLASS (GET_CODE (x)) == RTX_BITFIELD_OPS)
+{
+ enum machine_mode mode = GET_MODE(x);
+
Hi,
This patch removes REG_DEAD and REG_UNUSED notes in update_inc_notes,
as it is what the function is supposed to do (see the comments) and as
keeping these notes produce some failures, at least on ARM.
Thanks,
Yvan
2013-09-24 Yvan Roux yvan.r...@linaro.org
* lra.c
So can we assert that we have a REG here and use GET_MODE (XEXP (x, 0))? Or
else return false if we don't have a REG.
I'm currently testing the patch with the modification below
+static bool
+lsb_bitfield_op_p (rtx x)
+{
+ if (GET_RTX_CLASS (GET_CODE (x)) == RTX_BITFIELD_OPS)
+{
+
Thanks Eric, here is the new patch, validation is ongoing for ARM.
Yvan
2013-09-24 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka...@redhat.com
* rtlanal.c (lsb_bitfield_op_p): New predicate for bitfield operations
from the least significant bit
The description is too terse. In the RTL middle-end, you shouldn't have to
manually deal with the REG_DEAD and REG_UNUSED notes (unlike REG_EQUAL and
REG_EQUIV notes), as the DF framework is supposed to do it for you.
Sorry, for that. The description of the LRA function update_inc_notes
hmm, I don't see clearly where we loose the XEXP (x, n) information
when calling must_be_base_p(*inner) and/or must_be_index_p(*inner) in
set_address_base and set_address_index.
BTW, the validation on ARM (AARch32 and AARch64) is clean.
Thanks,
Yvan
On 24 September 2013 18:36, Richard Sandiford
Hi,
the needed lra analyser patch was commited as r202914.
Thanks,
Yvan
On 24 September 2013 11:03, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
The following patch switch LRA on for AArch64. The patch introduces
an undocumented option -mlra to use LRA instead of reload, for a
testing
(Added Eric and Richard)
Sorry for the inconvenience Iain, It's ok for my side.
Thanks,
Yvan
On 26 September 2013 13:18, Iain Sandoe i...@codesourcery.com wrote:
Hi Yvan,
On 24 Sep 2013, at 09:29, Yvan Roux wrote:
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here
Hi,
The status of LRA support for AArch32 is the sequel :
- there is some regressions in the testsuite (gcc/g++, libstdc++ and
fortran) in ARM mode, all due to the same neon legitimate address
issue (tested in hard and softfp mode).
- the compiler doesn't bootstrap with LRA enable for thumb
Hi,
after the discussion in the thread below I've committed the enabling
of LRA on ARM through the new option -mlra. Notice that we still rely
on reload until the regression has been resolved.
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00908.html
Thanks,
Yvan
2013-10-16 Yvan Roux yvan.r
Ping^2
I forgot this one was still pending.
On 13 August 2013 14:21, Yvan Roux yvan.r...@linaro.org wrote:
Ping.
On 23 July 2013 16:18, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
I forgot to add the test case with the PR fix, the attached patch add it.
Thanks,
Yvan
ChangeLog
gcc
(this time in plain text !)
Does this mean we can now turn on LRA for ARM state by default and
start looking at performance issues if any ?
With the other patch for 58785 and a small one I've to post, we are even
about to turn LRA on by default completely, as the compiler now bootstrap
also in
])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
Thanks,
Yvan
On 31 October 2013 17:31, Yvan Roux yvan.r...@linaro.org wrote:
(this time in plain text !)
Does this mean we can now turn on LRA for ARM state by default and
start looking at performance issues if any
when LRA is on.
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00725.html
Thanks,
Yvan
2013-11-07 Yvan Roux yvan.r...@linaro.org
* config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Return NO_REGS
for LRA.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 1781b75
Can the fix be back ported?
Yes, the back port on 4.7 is straightforward, it just needs to be commited.
Yvan
Hi,
I'm agree. I looked at the ARM backend and it occurs that the usage
of optimize_insn_for_size_p() was added to only use store_minmax in
cold path because of some performance issue. But in any case its
usage doesn't shrink the number of instruction, if we are in ARM mode
3 are needed : 1
Sometimes 4 will be needed, since both original register values may
remain live.
Indeed.
However, I'm inclined to agree that while it should be possible to
decide at the *function* level whether or not an insn is valid, doing so
at the block level is probably unsafe.
Ok, so the attached
So, the validation is ok with this patch, I'm just not able to say if
the original performance issue is still fixed with it. Could you
check it Kyrylo ?
Yvan
2013-11-17 Yvan Roux yvan.r...@linaro.org
* config/arm/arm.md (store_minmaxsi): Use only when
Ping.
On 7 November 2013 15:56, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
this patch fixed an LRA cycling due to secondary reload (Thumb mode).
Notice that this patch is a prerequisite to turn on LRA by default on
ARM. Bootstrapped on a9 and a15 without any regression in the
testsuite
Hi Yvan,
I'll run the benchmark today to confirm the performance, but from compiling
some code sequences that exhibited the bad behaviour in the past, I see that
this patch still fixes the issues. store_minmaxsi is not generated when
optimising for speed.
Ok Cool, Thanks Kyrill
Cheers,
Yvan
yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Yvan
Hi,
as Richard said, only a subset of rclass is allowed to be returned by
preferred_reload_class. I've tested the attached patched in Thumb
mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
Yvan
2013-11-20 Yvan Roux yvan.r...@linaro.org
PR target/58785
Ping
On 18 November 2013 09:40, Yvan Roux yvan.r...@linaro.org wrote:
Ping.
On 7 November 2013 15:56, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
this patch fixed an LRA cycling due to secondary reload (Thumb mode).
Notice that this patch is a prerequisite to turn on LRA by default on
ARM
Ping.
On 19 November 2013 09:52, Yvan Roux yvan.r...@linaro.org wrote:
yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Yvan
Ping.
On 20 November 2013 10:22, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
as Richard said, only a subset of rclass is allowed to be returned by
preferred_reload_class. I've tested the attached patched in Thumb
mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
Yvan
2013
Please include either the patch you are pinging or at the least a link to it
in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux yvan.r...@linaro.org
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p
How can that be correct?
The secondary reload macros/hooks define cases where additional registers
are needed to reload certain forms of rtl. I doubt the use of LRA
completely eliminates the need for secondary reloads.
Vladimir explained me that in that case on arm, secondary reload hook
On 27 November 2013 18:58, Vladimir Makarov vmaka...@redhat.com wrote:
On 11/27/2013, 12:16 PM, Jeff Law wrote:
On 11/27/13 03:18, Yvan Roux wrote:
Ping
On 18 November 2013 09:40, Yvan Roux yvan.r...@linaro.org wrote:
Ping.
On 7 November 2013 15:56, Yvan Roux yvan.r...@linaro.org wrote
On 27 November 2013 19:13, Jeff Law l...@redhat.com wrote:
On 11/27/13 10:30, Yvan Roux wrote:
Please include either the patch you are pinging or at the least a link to
it
in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux yvan.r
, but was a bit lazy in the description ;)
I've tested the attached patched in Thumb
mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
Yvan
2013-11-20 Yvan Roux yvan.r...@linaro.org
PR target/58785
* config/arm/arm.c (arm_preferred_reload_class): Only
On 27 November 2013 19:27, Jeff Law l...@redhat.com wrote:
On 11/27/13 10:49, Yvan Roux wrote:
How can that be correct?
The secondary reload macros/hooks define cases where additional registers
are needed to reload certain forms of rtl. I doubt the use of LRA
completely eliminates the need
Hi,
any news on this one, as the issue with --with-sysroot and
--with-gxx-include-dir is still present in 4.8 ?
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00320.html
Thanks,
Yvan
PS. Sorry for the re-post, I don't have the original one in my history
Hi,
for AArch64 it is also needed to take into account SIGN_EXTRACT in the
set_address_base and set_address_index routines, as we acan encounter
that kind of insn for instance :
(insn 29 27 5 7 (set (mem:SI (plus:DI (sign_extract:DI (mult:DI
(subreg:DI (reg/v:SI 76 [ elt ]) 0)
...
with the
Hi,
I forgot to add the test case with the PR fix, the attached patch add it.
Thanks,
Yvan
ChangeLog
gcc/testsuite
2013-07-23 Yvan Roux yvan.r...@linaro.org
PR target/57909
* gcc.target/arm/pr57909.c: New test.
On 17 July 2013 10:58, Ramana Radhakrishnan ramra...@arm.com
Ping.
On 23 July 2013 16:18, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
I forgot to add the test case with the PR fix, the attached patch add it.
Thanks,
Yvan
ChangeLog
gcc/testsuite
2013-07-23 Yvan Roux yvan.r...@linaro.org
PR target/57909
* gcc.target/arm/pr57909
Hi Vladimir,
I've some regressions on ARM after this SP elimination patch, and they
are execution failures. Here is the list:
g++.dg/cilk-plus/AN/array_test_ND_tplt.cc -O3 -fcilkplus
gcc.c-torture/execute/va-arg-22.c -O2
gcc.dg/atomic/c11-atomic-exec-5.c -O0
gfortran.dg/direct_io_12.f90
Pragmatically, I think it's time we turned LRA on by default now that
we are in stage3 and that would help with getting more issues out of
the auto-testers quicker than anything else. Given we are now well
into stage3, we should make sure that the LRA support gets as much
testing as it can
Thanks
Yvan
2013-12-11 Yvan Roux yvan.r...@linaro.org
* config/arm/arm.opt (mlra): Enable LRA by default.
Index: gcc/config/arm/arm.opt
===
--- gcc/config/arm/arm.opt (revision 205885)
+++ gcc/config/arm/arm.opt
bootstrap seems to be broken with an ICE in check_rtl, I'm
checking if it is the same issue.
Yvan
On 12 December 2013 20:18, Vladimir Makarov vmaka...@redhat.com wrote:
On 12/11/2013, 1:59 PM, Yvan Roux wrote:
On 11 December 2013 19:25, Vladimir Makarov vmaka...@redhat.com wrote:
On 12/11/2013
Thanks for the fix Vladimir, I confirm that most of ARM regression are
fixed, and Thumb2 bootstrap is ok. I'm still working on sorting out
the remaining regressions, most of them are on Thumb1.
Thanks
Yvan
On 13 December 2013 22:10, Vladimir Makarov vmaka...@redhat.com wrote:
On 12/13/2013,
On 17 December 2013 00:03, Vladimir Makarov vmaka...@redhat.com wrote:
On 12/13/2013, 8:07 AM, Yvan Roux wrote:
Thanks for your help Vlad. Another bad news about this PR fix, is
that it has resurrected the thumb_movhi_clobber bug (PR 58785) but in
a different manner as the original failing
Hi,
this patch from Vladimir fixes an ICE when compiling newlib in Thumb1.
It returns NO_REGS in THUMB_SECONDARY_OUTPUT_RELOAD_CLASS, the same
way we did for THUMB_SECONDARY_INPUT_RELOAD_CLASS.
The testsuite is OK with this patch, but as we have also a regression
on iWMMXT, I tried to avoid the
A quick grep of the arm backend shows 11 instances of reload_in_progress:
arm.c: !(reload_in_progress || reload_completed)
arm.c: if (! (reload_in_progress || reload_completed)
arm.c: if (! (reload_in_progress || reload_completed)
arm.c: if (! (reload_in_progress ||
Thanks for the hint Vladimir, I'll pass some validation on arm.c and
arm.md/aarch64.md separately.
On 14 January 2014 20:09, Vladimir Makarov vmaka...@redhat.com wrote:
On 01/14/2014 01:41 PM, Yvan Roux wrote:
A quick grep of the arm backend shows 11 instances of reload_in_progress:
arm.c
, NORMAL)
Leaked composite object at 0x7f91e14fe0
(/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21,
sz=4, NORMAL)
Regards,
Yvan
2013-03-16 Yvan Roux yvan.r...@linaro.org
* include/private/gcconfig.h (AARCH64): New macro (defined
only if
__aarch64__
Ping (second try)
Sorry if you received it twice, it seems that my gmail account
switched in text/html mode :(
Many thanks,
Yvan
On 2 April 2013 11:21, Yvan Roux yvan.r...@linaro.org wrote:
Ping
On 17 March 2013 21:34, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
this is a backport from
of the 'Free for all' section of
http://gcc.gnu.org/svnwrite.html#policies is that since this is a
backport from an upstream project you do not need to seek further
approval to commit this change.
Cheers
/Marcus
On 2 April 2013 11:50, Yvan Roux yvan.r...@linaro.org wrote:
Ping (second try)
Sorry
Hi all
we have merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 213802 as r213944. We have also backported this set of revisions:
r204251 as r213841 PR sanitizer/58543
r206529 as r213842 PR target/59744
r206530 as r213842 PR target/59744 / fix changelog typo
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 213803 as r213943. We have also backported this set of revisions:
r211140 as r213455 [AArch64] Drop ISB after FPCR write.
r211270 as r213790 [AArch64] Remove from arm_neon.h functions not
in the spec
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 218412 as r218423. We have also backported this set of revisions:
* r213382 as r218352 : [AArch64] arm_neon.h - add vpaddd_f64,
vpaddd_s64, vpaddd_u64 intrinsics
* r214008 as r218354 : [AArch64] Move some code
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 219502 as r219549. We have also backported this set of revisions:
* r209620 as r219434 : [AArch64] Support SISD variants of SCVTF,UCVTF
* r209800 as r219597 : Add clobber_reg
* r211075 as r219465 : Add execution
(but not on an
IWMMXT one), is it ok for trunk and 4.9 branch ?
Rq: I think that adding IP and CC clobbers to
CALL_INSN_FUNCTION_USAGE, as specified by AAPCS, in 4.9 branch is
something we need too, I've a patch for that if you agree on that.
Thanks,
Yvan
2105-03-17 Yvan Roux yvan.r...@linaro.org
PR
HI Kyrill,
On 18 March 2015 at 11:24, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi Yvan,
On 18/03/15 10:19, Yvan Roux wrote:
Hi,
This is a fix for PR64208 where LRA loops when dealing with
iwmmxt_arm_movdi insn. As explain in the PR, the issue was introduced
on trunk and 4.9 branch
On 18 March 2015 at 12:42, Yvan Roux yvan.r...@linaro.org wrote:
HI Kyrill,
On 18 March 2015 at 11:24, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi Yvan,
On 18/03/15 10:19, Yvan Roux wrote:
Hi,
This is a fix for PR64208 where LRA loops when dealing with
iwmmxt_arm_movdi insn
Ping.
On 11 March 2015 at 16:38, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
PR ipa/65236
* cgraphunit.c (cgraph_node::expand_thunk): Enable return slot
opt.
This bugfix adds ipa-icf-6.C test which failed on 4.9 branch as
ipa-icf is not backported on that branch
Yvan Roux yvan.r...@linaro.org
Backport from trunk r220489.
2015-02-06 Jakub Jelinek ja...@redhat.com
PR ipa/64896
* cgraphunit.c (cgraph_node::expand_thunk): If
restype is not is_gimple_reg_type nor the thunk_fndecl
returns aggregate_value_p, set restmp to a temporary
-linux-gnueabihf
i686-linux-gnu
Ok for 4.9 ?
Thanks
Yvan
- PR 63587 -
gcc/
2015-03-11 Yvan Roux yvan.r...@linaro.org
Backport from trunk r216841.
2014-10-29 Martin Liska mli...@suse.cz
PR ipa/63587
* cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 221341 as r221360. We have also backported this set of revisions:
* r212011 as r221216 : PR tree-optimization/61607
* r214942 as r221216 : Abstract away marking loops for removal
* r214957 as r221216 : Sanity
Hi
On 9 March 2015 at 17:07, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
As added in the PR, this issue is also present on 4.9 branch and
affects at least arm-linux-gnueabihf target (as reported in PR61207).
I've backported it in the 4.9 branch with the attached patch. The
difference
On 10 March 2015 at 19:18, Jan Hubicka hubi...@ucw.cz wrote:
Hi
On 9 March 2015 at 17:07, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
As added in the PR, this issue is also present on 4.9 branch and
affects at least arm-linux-gnueabihf target (as reported in PR61207).
I've backported
Honza,
On 10 March 2015 at 20:09, Yvan Roux yvan.r...@linaro.org wrote:
On 10 March 2015 at 19:18, Jan Hubicka hubi...@ucw.cz wrote:
Hi
On 9 March 2015 at 17:07, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
As added in the PR, this issue is also present on 4.9 branch and
affects at least
Hi Xingxing,
do you know if it is possible to test this patch inside Marvell (as it
is a fix for iWMMXT arch.) ?
Thanks a lot
Yvan
On 23 March 2015 at 18:47, Yvan Roux yvan.r...@linaro.org wrote:
Hi,
On 23 March 2015 at 17:08, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Wed
on scheduling as the type attribute affected to alt 4 is
alu_imm when it could only involve registers.
This is fixed by this small patch. Cross builded and regtested for
arm/armeb targets.
Ok for trunk (maybe for stage 1 as no PR is attached to that) ?
Cheers,
Yvan
2105-03-24 Yvan Roux yvan.r
1 - 100 of 184 matches
Mail list logo
