in just
carrying the noise with these extra failures. Christophe and I will
testdrive his testsuite work in this space with these patches to see how
the conversion process works and if there are any issues with these patches.
If there are issues I'm happy to hear about them.
Will a
these patches to see how
the conversion process works and if there are any issues with these patches.
Ramana Radhakrishnan
* config/arm/arm_neon.h (vadd_s8): GNU C implementation
(vadd_s16): Likewise.
(vadd_s32): Likewise.
(vadd_f32): Likewise.
ctured the dead code elimination as Patch 2/3.
This will be committed separately in case folks want to backport Patch
1/3 separately and want to assure their users of LTO compatibility
within a release branch (if that even works) .
Ramana Radhakrishnan
* config/arm/arm_neon_bui
-schedgen.ml, neon.ml and neon-testgen.ml. I think we
can safely remove neon-testgen.ml once Christophe's testsuite is done
and we'll probably just have to carry neon-schedgen.ml / neon.ml as it
still generates the neon descriptions for both a8 and a9.
Ramana Radhakrishnan
On 04/28/14 11:48, Ramana Radhakrishnan wrote:
Patch 3/3 removes the ML to generate Neon intrinsics and the
documentation and updates the comments in the files to show that these
are now hand crafted rather than auto-generated. We've had these for
many years now and I think it's time
): New function.
+ * config/aarch64/aarch64.md (stfpscr): New pattern.
+ (ldfpscr) : Likewise.
+ (unspecv): Add UNSPECV_LDFPSCR and UNSPECV_STFPSCR.
+
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
any opinions on the way in which the tests are being
structured ?
Ramana
>
> Thanks,
>
> Christophe.
>
>
> On 15 April 2014 19:38, Christophe Lyon wrote:
>> On 15 April 2014 16:18, Ramana Radhakrishnan
>> wrote:
>>> On 04/14/14 23:16, Christophe Lyon wrote
On Mon, Apr 28, 2014 at 12:44 PM, Julian Brown
wrote:
> On Mon, 28 Apr 2014 11:44:01 +0100
> Ramana Radhakrishnan wrote:
>
>> I've special cased the ffast-math case for the _f32 intrinsics to
>> prevent the auto-vectorizer from coming along and vectorizing a
On Thu, Mar 27, 2014 at 10:53 AM, Alan Lawrence wrote:
> Final patch adds new tests of the ARM ZIP Intrinsics (subsuming the
> autogenerated ones in testsuite/gcc.target/arm/neon/), that also check the
> execution results, reusing the test bodies introduced into AArch64 in the
> first patch.
>
> A
On Wed, Apr 23, 2014 at 9:32 PM, Alan Lawrence wrote:
> Final patch in series, adds new tests of the ARM EXT Intrinsics, that also
> check
> the execution results, reusing the test bodies introduced into AArch64 in
> the
> first patch. (These tests subsume the autogenerated ones in
> testsuite/gcc
On Thu, Mar 27, 2014 at 5:28 PM, Alan Lawrence wrote:
> inal patch in series, adds new tests of the ARM UZP Intrinsics (subsuming
> the autogenerated ones in testsuite/gcc.target/arm/neon/), that also check
> the execution results, reusing the test bodies introduced into AArch64 in
> the first pat
On 05/07/14 09:19, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov
To: Ramana Radhakrishnan
CC: gcc-patches@gcc.gnu.org , Viacheslav
Garbuzov , Yury Gribov
Hi,
This fixes
On Wed, May 7, 2014 at 2:13 AM, Paolo Carlini wrote:
> -- Francois,
>
> remember to regenerate and commit the Makefile.in changes.
Can someone regenerate and commit the Makefile.in changes soon ? I'm
seeing testsuite failures thanks to missing debug/safe_container.h on
arm-none-linux-gnueabihf
I
On Wed, May 7, 2014 at 2:22 PM, Jonathan Wakely wrote:
> On 07/05/14 14:17 +0100, Ramana Radhakrishnan wrote:
>>
>> Can someone regenerate and commit the Makefile.in changes soon ? I'm
>> seeing testsuite failures thanks to missing debug/safe_container.h on
>> a
e architectures
which use UDWType in longlong.h. I noticed this when trying rth's
patch stack http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00391.html to
improve longlong.h for AArch64.
It's needed when rth's patches go in finally for aarch64 but could
probably go in now - after
+#if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
W_TYPE_SIZE == 32 is always false and on 32-bit hosts,
__SIZEOF_INT128__ won't be defined.
Right, but we won't try to use TImode if in future we do revert to using
32-bit types for 32-bit hosts.
For now, I've re
ase on arm-none-linux-gnueabihf noting that
the test is now UNSUPPORTED.
Ok to apply ?
regards
Ramana
Ramana Radhakrishnan
* lib/target-supports.exp
(check_effective_target_vect_float_divide): New.
* gfortran.dg/vect/pr48329.f90: Use this.
Ramana Radhakrishnan
On 05/06/14 14:37, Kyrill Tkachov wrote:
Hi all,
This patch removes the NEON builtin functions for vtrn, vzip, vuzp and their
associated wiring and machine descriptions. The builtins were initially used to
implement the corresponding intrinsics in arm_neon.h but those have since been
reimplement
y for little-endian, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062). I have a fix for this and
shall post shortly.
Cheers, Alan
Ramana Radhakrishnan wrote:
On Fri, Mar 28, 2014 at 3:50 PM, Alan Lawrence wrote:
Final patch in series, adds new tests of the ARM TRN Intrinsics, that also
check
On Thu, May 15, 2014 at 11:33 AM, Jakub Jelinek wrote:
> On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > This patch adds two new options (compatible with clang) which allow
>> > users to choose the behavior of undefined behavior sanitization.
>> >
>
> Btw, the bswap pass enhancements that are currently in review may
> also be an opportunity to catch these. They can merge adjacent
> loads that are used "composed" (but not yet composed by storing
> into adjacent memory). The basic-block vectorizer should also
> handle this (if the compositio
The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
progress.
Patches must be proposed on gcc-patches and / or in thi
On 05/20/14 17:05, Alexey Merzlyakov wrote:
Hi all,
This is a fix for thumb1 build fail on trunk appeared since
rev.210515(pr60758).
On thumb1 targets the LR can not be used as argument of POP instruction.
To keep a support of __cxa_end_cleanup backtracing on thumb1
we can make additional regis
-(define_split
+; Split the load of 64-bit constant into two loads for high and low
32-bit parts respectively
+; to see if we can load them in fewer instructions or fewer cycles.
+; For the small 64-bit integer constants that satisfy constraint J,
the instruction pattern
+; thumb1_movdi_insn has a
On Wed, May 21, 2014 at 10:29 AM, Terry Guo wrote:
>
>
>> -Original Message-----
>> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
>> Sent: Wednesday, May 21, 2014 4:56 PM
>> To: Terry Guo
>> Cc: gcc-patches; Richard Earnshaw; Ramana Radha
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
>> FAIL: gcc.target/aarch64/table-intrinsics.c (internal compiler error)
>> FAIL: gcc.target/aarch64/table-intrinsics.c (test for excess errors)
>> Excess errors:
>> /work/gcc-clean/src/gcc/gcc/testsuite/gcc.target/aarch64/table-intrinsics.c:17
On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
wrote:
> On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
>> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>>> A new patch based on r209283.
>>> This one has the H.J.'s patches for x32.
>>
>> Ok for trunk then.
On 05/23/14 08:50, Yury Gribov wrote:
> On ARM the asan tests have always been a random generator of PASS /
> FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps
> outputs.
This should improve once upstream Asan sets up an ARM build bot. This
has been discussed recently but n
Looks good except for :
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index ef370fe..7e1ec71 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3280,7 +3280,8 @@ proc check_effective_target_vect_bswap { }
On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka wrote:
> Hi,
> this patch adds code to rerite references in vtable initializers to local
> aliases
> when doing so is a win.
>
> Bootstrapped/regtested x86_64-linux, comitted.
This is the most likely patch to have caused build failures on
arm-linux-gn
On Mon, May 26, 2014 at 2:04 AM, Jan Hubicka wrote:
>> > On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka wrote:
>> > > Hi,
>> > > this patch adds code to rerite references in vtable initializers to
>> > > local aliases
>> > > when doing so is a win.
>> > >
>> > > Bootstrapped/regtested x86_64-linux
On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
wrote:
> Hi,
>
> Commits 210964 and 210965 for this patch have broken GCC build on arm*
> targets.
> For instance on target arm-none-linux-gnueabi, when creating
> unwind-arm.o, I can see:
> /tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf
On Tue, May 27, 2014 at 3:31 PM, Maciej W. Rozycki
wrote:
> On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
>
>> > On 08/09/13 11:01, Julian Brown wrote:
>> > > On Thu, 8 Aug 2013 15:44:17 +0100
>> > > Kyrylo Tkachov wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> The recently added gcc.target/arm/pr580
On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote:
>> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
>> > It's being called form basically two files:
>> >
>> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ fin
On Wed, May 28, 2014 at 9:30 AM, Richard Earnshaw wrote:
> Ah, light dawns (maybe).
>
> I guess the problems stem from the attempts to combine Neon with ARMv5.
> Neon shouldn't be used with anything prior to ARMv7, since that's the
> earliest version of the architecture that can support it.
>
>
On Wed, May 28, 2014 at 6:49 PM, Mike Stump wrote:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>>
>> Speed of implementation. We're gradually replacing these with proper
>> builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a
On Sat, May 24, 2014 at 5:54 PM, Jonathan Wakely wrote:
> On 24 May 2014 17:07, David Edelsohn wrote:
>> This patch broke the ability to run the libstdc++ testsuite on AIX.
>>
>> I now see the following errors:
>>
>> bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line,
>> -
On Fri, May 30, 2014 at 9:14 AM, Tom de Vries wrote:
> Marcus,
>
> when building for aarch64-linux-gnu with --enable-checking=yes,rtl, I run
> into the following error:
> ...
> In file included from src/libgcc/libgcc2.c:56:0:
> src/libgcc/libgcc2.c: In function ‘__floattisf’:
> src/libgcc/libgcc2.
On 05/29/14 16:25, Kyrill Tkachov wrote:
Hi all,
I noticed that in some of our move patterns the movw instruction is given the
mov_reg type rather than the
mov_imm type that all other uses of movw have. This patch fixes that.
Scanning through our pipeline descriptions I see that mov_imm is tre
>+ if (!TARGET_VFP)
>+return;
>+
>+ /* Generate the equivalence of :
s/equivalence/equivalent.
Ok with that change and if no regressions.
Ramana
On Mon, May 26, 2014 at 9:01 AM, Kugan
wrote:
> Ping^2 ?
>
> Thanks,
> Kugan
>
> On 12/05/14 09:47, Kugan wrote:
>> Ping ?
>>
>> Thanks,
>> Kug
deal with that
separately given the current state of brokenness in the tree.
Tested with a bootstrap again today on top of 211072 and earlier
regression tests showed no regressions.
Will apply once regression tests finish.
regards
Ramana
Ramana Radhakrishnan
* config/arm/arm.h (TARGET_SU
On Thu, May 29, 2014 at 3:17 PM, Yufeng Zhang wrote:
> Hi Honza,
>
> I can confirm that with your commit r211045 the arm-none-linux-gnueabi{hf}
> builds are OK now. Thanks for the fix.
Testsuite regressions like
FAIL: g++.dg/ipa/devirt-21.C -std=gnu++1y (test for excess errors)
Excess errors:
On 21/01/14 10:52, James Greenhalgh wrote:
+ names passed from the commend line will be in ARGV, we want
s/commend/command.
Otherwise OK if no regressions.
Thanks,
Ramana
og:
> 2014-01-16 Zhenqiang Chen
>
> PR target/59837
> * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add
> REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled.
>
> testsuite/ChangeLog:
> 2014-01-16 Zhenqiang Chen
>
> * gcc.target/arm/pr
On Thu, Jan 23, 2014 at 3:16 PM, Yury Gribov wrote:
> Hi,
>
> Julian Brown has proposed patch
> (http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01191.html) for the dreadful
> push_minipool_fix error (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423)
> in June but it didn't seem to get enough attent
On Fri, Jan 24, 2014 at 5:16 PM, Ian Bolton wrote:
> Hi there!
>
> An existing optimisation for Thumb-2 converts t32 encodings to
> t16 encodings to reduce codesize, at the expense of causing
> redundant flag setting for ADD, AND, etc. This redundant flag
> setting can have negative performance i
On Fri, Dec 20, 2013 at 6:50 PM, Renlin Li wrote:
> Hi all,
>
> This patch will add armv7ve support to gcc. Armv7ve is basically a armv7-a
> architecture profile with Virtualization Extensions. Additional test cases
> are also added.
>
> With this patch and to keep backward compatibility with old
-thumb.c: Change aramv7-a to armv7-a.
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
On Mon, Feb 3, 2014 at 3:14 PM, Yury Gribov wrote:
>> Additionally I'm not really sure
>> why there is an additional load from the constant pool here - what is
>> the constant in this case ?
>> Given it is atmost a 16 bit constant
>> surely that should be loaded with a single mov(w) instruction
>>
or_misalignment): Likewise.
+
+2014-02-03 Yury Gribov
+Kugan Vivekanandarajah
+
+ * gcc.target/arm/vect-noalign.c: New file.
+
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
ppropriate parts of this option.
Ok with those changes.
Thanks,
Ramana
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
nks,
James
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
Ramana wrote:
Attached patch fixes this. Is this OK for trunk?
How has it been tested ?
I was hoping Linaro people could run their magical cbuild on it...
Ok if no regressions.
regards
Ramana
-Y
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
On Thu, Jan 30, 2014 at 8:38 PM, Jakub Jelinek wrote:
> Hi!
>
> For -Os, apparently ARM backend sometimes decides to push (up to 8?) dummy
> registers to stack in addition to the registers that actually need to be
> saved, in order to avoid extra instruction to adjust stack pointer.
> These regist
On Thu, Jan 30, 2014 at 1:45 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds the rtx costs table for Cortex-A57 and sets its issue rate
> properly in the arm backend.
>
> Tested on arm-none-eabi on a model.
>
>
> Ok for trunk?
In my view this is OK - this is just a tuning patch for A57 an
On Tue, Feb 4, 2014 at 2:12 AM, Michael Hudson-Doyle
wrote:
> Ping? I'm attaching a marginally cleaner version of the test. I've had
> a look at integrating this into aapcs64.exp but got defeated in the
> end. If go-torture-execute took a list of sources as c-torture-execute
> does, then I thin
On Mon, Feb 3, 2014 at 11:39 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This patch updates the thumb2_movhi_insn pattern for the -mrestrict-it
> rules. I had somehow missed it when doing the -mrestrict-it work last year,
> and it is possible to generate a deprecated IT block form in ARMv8 Thumb2
> co
On Mon, Feb 10, 2014 at 11:01 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This patchlet adds the part numbers for the Cortex-A53 and A57 cores so that
> they can be detected when parsing /proc/cpuinfo on AArch32 Linux systems.
> This will allow the -mcpu=native machinery to detect those cores.
>
> Tes
On Mon, Feb 3, 2014 at 3:56 PM, Renlin Li wrote:
> Hi all,
>
> This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c is
> checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for the
> target.
>
> Accordingly, two procs (check_effective_target_arm_vfp3_ok and
> add_op
ana
Thanks,
James
---
2014-02-12 James Greenhalgh
* config/arm/aarch-common-protos.h
(alu_cost_table): Fix spelling of "extend".
* config/arm/arm.c (arm_new_rtx_costs): Fix spelling of "extend".
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
rtexa12_extra_costs): Likewise.
(cortexa15_extra_costs): Likewise.
(v7m_extra_costs): Likewise.
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
On Tue, Feb 18, 2014 at 9:09 PM, Philipp Tomsich
wrote:
> The following patch-set contains the pipeline-independent changes to gcc
> to support the APM XGene-1 and contains various enhancements derived from
> real-world applications and benchmarks running on XGene-1.
>
> As the pipeline model has
>> Or, if ARM supports unaligned loads/stores using special instructions,
>> perhaps you should also benchmark the alternative of not realigning, but
>> instead making sure those unaligned instructions are used for the shadow
>> memory loads/stores in the asan prologue/epilogue.
> I have tried to u
On 02/26/14 01:54, Terry Guo wrote:
Hi There,
As the assembler directive ".code 16" equals ".thumb", this small patch is
going to redefine the ASM_APP_OFF in a cleaner way. Tested with GCC
regression test and no regressions. Is it OK to current trunk or shall we
wait until the release-branch mod
(in this case we can only have atomic access to 8byte objects on 8 byte
aligned addresses).
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 2f06e42..aad420c 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
usage and a generally improved register allocation strategy.
Queued for stage1 after suitable testing including a bootstrap and
regression test in Thumb2 found no issues.
regards
Ramana
Ramana Radhakrishnan
* config/arm/arm.c (arm_hard_regno_mode_ok): Loosen
restrictions on core
-none-elf on a model with no regressions.
Ok for stage1 ?
regards
Ramana
Ramana Radhakrishnan
* config/aarch64/aarch64.c (TARGET_FLAGS_REGNUM): Define.
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index
On Fri, Feb 28, 2014 at 2:42 AM, Joey Ye wrote:
> Ping. OK for trunk and 4.8?
Ok if no regressions.
Ramana
>
>> -Original Message-
>> From: Joey Ye [mailto:joey...@arm.com]
>> Sent: 21 February 2014 19:32
>> To: gcc-patches@gcc.gnu.org
>> Subject: [patch] [arm] Fix PR60169 - thumb1 far
On Fri, Feb 28, 2014 at 7:16 AM, Joey Ye wrote:
> This patch is a mirror copy from approved patch in glibc:
> http://sourceware.org/ml/libc-alpha/2014-02/msg00741.html
>
> OK to trunk, 4.8 and 4.7?
OK everywhere.
Ramana
>
> ChangeLog.libgcc:
>
> * config/arm/sfp-machine.h (_FP_NANFRAC_H,
> _F
Hi Ramana,
This is the rebased patch, there is no conflict against latest trunk. I am
still doing some tests. Is it OK if tests are fine?
Also, it depends on patch at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html, I will update that
patch two.
Thanks,
bin
Index: gcc/config/arm
On Tue, Jul 8, 2014 at 10:59 AM, Alan Lawrence wrote:
> No regressions on arm-none-eabi or armeb-none-eabi; also FAIL->PASS on local
> copies of the execution-result tests in gcc.target/arm/simd tests (taken
> from mainline, these are not present in 4.9).
Ok unless an RM objects. I suspect the pr
On Mon, Jun 23, 2014 at 11:05 AM, Alan Lawrence wrote:
> 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?
Ok Makes life with backpor
On Thu, Jul 3, 2014 at 4:08 PM, Alan Lawrence wrote:
> 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 tes
On 30/06/14 16:21, Marat Zakirov wrote:
Thank for your attention.
This is OK for trunk - Sorry about the delayed response.
Ramana
Marat.
On Thu, Jun 19, 2014 at 9:19 PM, Yuri Gribov wrote:
>> Thirdly, we also need to fix movhi_bytes (for pre-v4) thumb2_movhi_insn
>> (for thumb2) and, quite possibly, thumb1_movhi_insn (for thumb1). There
>> may well be additional changes for movqi variants as well.
>
> A general question: how shoul
On Fri, Jul 18, 2014 at 12:28 PM, Mikael Pettersson
wrote:
> John David Anglin writes:
> > Because the atomic sync functions in config/pa/linux-atomic.c are not
> > lock free, we need to use
> > __kernel_cmpxchg for the __sync_lock_release. This was found in
> > glibc's pthread_spin_unlock
>
On Mon, Jul 14, 2014 at 11:11 AM, Jiong Wang wrote:
> currently the following testcases are disabled for arm target,
>
> gcc.dg/ira-shrinkwrap-prep-1.c
> gcc.dg/ira-shrinkwrap-prep-2.c
> gcc.dg/pr10474.c
>
> the reason is on arm target, register r3 is caller-saved. Normally it does
> not need to
On Sat, Jul 12, 2014 at 11:40 PM, Kugan
wrote:
>>
>> - if (!TARGET_VFP)
>> -return;
>> + if (!TARGET_VFP || TARGET_THUMB1)
>> +return default_atomic_assign_expand_fenv (hold, clear, update);
>>
>> You don't need to call default function here. It is empty, the
>> documentation says:
>>
>>
>
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-109.c
> b/gcc/testsuite/gcc.dg/vect/vect-109.c
> index 854c970..fb87e2c 100644
> --- a/gcc/testsuite/gcc.dg/vect/vect-109.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-109.c
> @@ -1,4 +1,4 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-req
On Tue, Jul 29, 2014 at 10:19 AM, Jiong Wang wrote:
> the patch athttps://gcc.gnu.org/ml/gcc-patches/2014-07/msg00961.html
>
> actually has one glitch on if check.
>
> thumb target is code size sensitive, the best solution is we set
> "prefer_callee_reg_p" to
> true if we know that shrink-wrap wil
On 31/07/14 11:53, Christophe Lyon wrote:
On 5 July 2014 16:12, Charles Baylis wrote:
On 3 July 2014 15:26, Richard Earnshaw wrote:
So OK, but if you're considering back-ports, I suggest you let it bake a
while on trunk first.
Committed as r212303.
It was a few weeks ago now, so is it
On Wed, Jul 30, 2014 at 10:35 PM, Mike Stump wrote:
> On Jul 22, 2014, at 12:14 PM, Mike Stump wrote:
>> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov wrote:
>>> These tests use very large arrays as part of their loop interchange testing
>>> so they don't fit into the 1MiB binary size limit impos
This is OK thanks.
Ramana
On Wed, Mar 5, 2014 at 9:12 AM, Jakub Jelinek wrote:
> Hi!
>
> arm_legitimize_address may be called with a TLS symbol referenced, even when
> x is not itself a SYMBOL_REF. Most often it is something like:
> (const:SI (plus:SI (symbol_ref:SI "tlsvar") (const_int NNN)))
> but generally it can be so
On Tue, Jan 28, 2014 at 3:37 AM, Zhenqiang Chen
wrote:
> On 28 January 2014 01:07, Ramana Radhakrishnan
> wrote:
>> On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
>> wrote:
>>> Thanks for comments.
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?i
On Mon, Feb 24, 2014 at 9:11 AM, Christian Bruel wrote:
> This patch improves the one sent previously,
> (http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01159.html), to fix a few
> more failures in the testsuite that could arise with shrink-wrap and
> -fexceptions.
>
> To recall, the problem that i
On Fri, Mar 7, 2014 at 10:24 AM, Christian Bruel wrote:
> Hi Ramana,
>
> Thanks for your comments,
>
>> Please respin using plus_constant instead of gen_addsi3.
>
> Here is my feeling about this:
>
> I experimented on using plus_constant instead of gen_addsi3. But there
> are cases when the emitte
On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski wrote:
> On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
> wrote:
>> Hi Marcus,
>>
>>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>>> + [(set_attr "length" "12")])
>>>
>>> This pattern emits an opaque sequence of instructions that cannot be
MEMORY_MOVE_COST is in the default target hook implementation for
TARGET_MEMORY_MOVE_COST :)
Ok for stage4 ? Just rebuilt the compiler (cc1 and cc1plus), built a few
large enough .i files that I had lying around saw no difference in code
generated as expected.
regards,
Ramana
Ramana Radhakrishnan
/testsuite/gcc.target/arm/neon-modes-3.c
+++ b/gcc/testsuite/gcc.target/arm/neon-modes-3.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-require-effective-target arm_neon_ok } */
-/* { dg-options "-O" } */
+/* { dg-options "-O -g" } */
/* { dg-add-options arm_neon } */
#include
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
>
>
> gcc/
> * config/arm/predicates.md (call_insn_operand): Add long_call check.
> * config/arm/arm.md (sibcall, sibcall_value): Force the address to reg for
> long_call.
> * config/aarch64/aarch64.c (arm_function_ok_for_sibcall): Remove long_call
> restriction.
config/arm/arm.c :)
The ARM
ub Jelinek
Ramana Radhakrishnan
* dwarf2out.c (const_ok_for_output_1): Reject expressions containing a
NOT.
gcc/testsuite
Ramana Radhakrishnan
* gcc.c-torture/compile/pr60655-1.c: New test.
commit a0ccb2bce5e3179e7b3560ecd7eecea6289baf7b
Author: Ramana Radhakrishnan
Date:
verified that the correct multilibs are now chosen.
Applied to trunk as nearly obvious.
regards,
Ramana
2014-03-28 Ramana Radhakrishnan
* config/arm/t-aprofile (MULTILIB_MATCHES): Correct A12 rule.
Index: gcc/config/arm/t-aprofile
On Tue, Mar 25, 2014 at 3:51 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This two-patch series adds scheduling information for the ARMv8-A Crypto
> instructions on the Cortex-A53.
> This first patch does some preliminary restructuring to allow the arm and
> aarch64 backends to share the is_neon_type a
On Fri, Mar 28, 2014 at 5:18 PM, Kyrill Tkachov wrote:
> On 28/03/14 14:18, Ramana Radhakrishnan wrote:
>>
>> On Tue, Mar 25, 2014 at 3:51 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> This two-patch series adds scheduling informat
On Wed, Mar 19, 2014 at 9:55 AM, Kyrill Tkachov wrote:
> Hi all,
>
> In order to properly cost the rev16 instruction we need a new field in the
> cost tables.
> This patch adds that and specifies its value for the existing cost tables.
> Since rev16 is used to implement the BSWAP operation we add
On Wed, Mar 19, 2014 at 9:56 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This is the arm equivalent of patch [2/3] in the series that adds combine
> patterns for the bitwise operations leading to a rev16 instruction.
> It reuses the functions that were put in aarch-common.c to properly cost
> these op
On Wed, Mar 19, 2014 at 9:55 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds a recogniser for the bitmask,shift,orr sequence of
> instructions that can be used to reverse the bytes in 16-bit halfwords (for
> the sequence itself look at the testcase included in the patch). This can be
> imp
On Tue, Mar 25, 2014 at 3:52 PM, Kyrill Tkachov wrote:
> Hi all,
>
> In ARMv8-A there's a general expectation that AESE/AESMC and AESD/AESIMC
> sequences of the form:
>
> AESE Vn, _
> AESMC Vn, Vn
>
> will issue both instructions in a single cycle on super-scalar
> implementations. It would be nic
rm/pr60650.c
...
+ asm ("1\t.long ");
This asm looks quite bogus, and with
asm ("");
it ICEs the same way, can it be changed?
+ __builtin_unreachable ();
+ }
+}
Jakub
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.diff --git a/gcc/test
901 - 1000 of 1421 matches
Mail list logo
