> OK?
>
This is largely OK modulo the following.
Please remove the alternatives in the subsi3 pattern since that is just
unnecessary. Please make the constraints internal only.
cheers
Ramana
> Andrew
Would you include this in your patch? Or should we submit it as a
separate patch?
Could you submit this as a follow-up patch that touches the costs. I
would rather that these changes also went in when we were looking at
this area ?
cheers
Ramana
On 2 June 2011 10:03, Andrew Stubbs wrote:
> On 02/06/11 09:23, Ramana Radhakrishnan wrote:
>>
>> Please remove the alternatives in the subsi3 pattern since that is just
>> unnecessary. Please make the constraints internal only.
>
> Is this better?
>
OK.
Ramana
> Andrew
>
On 01/06/11 18:27, Ramana Radhakrishnan wrote:
2011-05-31 Ramana Radhakrishnan
* config/arm/neon.md (orndi3_neon): Actually split it.
This is what I committed in the end after a round of testing.
Ramana
Index: gcc/config/arm/neon.md
On 31 May 2011 11:03, Nathan Sidwell wrote:
> On 05/27/11 01:47, Ramana Radhakrishnan wrote:
>
>> Could you consider adding a check in the configury to test if a binutils
>> version
>> of recent vintage is being used when --with-tls=gnu is in ?
>
> I thought about th
> If you're asking something else, can you rephrase the question?
Sorry if I wasn't too clear. My question really should have read "why
do we have to special case Thumb2" ? The linker should be able to
veneer the t-> a calls either through the veneering sequence (in case
of T1 without blx) or con
On 6 June 2011 10:56, Nathan Sidwell wrote:
> On 06/06/11 10:53, Ramana Radhakrishnan wrote:
>>>
>>> If you're asking something else, can you rephrase the question?
>>
>> Sorry if I wasn't too clear. My question really should have read "why
&g
on armv7-a for qemu in both ARM and Thumb2 state using
arm-linux-gnueabi.
I will commit this in 24 hours if there are no objections.
cheers
Ramana
2011-06-03 Ramana Radhakrishnan
Richard Earnshaw
* config/arm/arm.c (const_ok_for_op): Check to see
if mvn c
v7-a cross in both ARM and Thumb configurations on qemu
with no regressions for C, C++ and Fortran.
Ok (and to backport to 4.6 branch) ?
cheers
Ramana
2011-06-09 Ramana Radhakrishnan
PR target/49335
* config/arm/predicates.md (add_operator): New.
* config/arm/a
cking.
cheers
Ramana
2011-06-10 Ramana Radhakrishnan
PR target/48454
* config/arm/neon.md (vec_pack_trunc): Set the lengths
correctly for the case with Quad vectors.
---
gcc/config/arm/neon.md |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
This caused http://gcc.gnu.org/PR49398.
You might also consider putting the PR numbers in your commit log in
the future that these patches attempt to fix so that the PR's in
bugzilla get the associated commit message. Please add links to this
commit to the individual PRs this commit attempts to fi
>
> I'm re-testing the attached version.
Shouldn't this be backported to release branches - specifically 4.6
(and 4.5 since this is where TARGET_VFP_SINGLE was introduced) ?
cheers
Ramana
On 14 June 2011 21:35, Janis Johnson wrote:
> These tests apparently require thumb2 support (I don't yet know much
> about ARM). OK for trunk, and later 4.6?
OK - The -march=armv7-a is redundant in these tests. You should be
able to lose them if arm_thumb2_ok returns true.
cheers
Ramana
e cases as well.
This *gross* hack below allows testing to proceed atleast for tls.exp
as far as arm-linux-gnueabi is concerned. What's the best way of
taking this forward ?
cheers
Ramana
2011-06-15 Ramana Radhakrishnan
* lib/wrapper.exp (target-support.exp): Load it.
(${too
> The patch isn't suitable as is. If -PIE requires -fPIC, then anything that
> adds it or tortures on it, should add both, or torture on both.
The ABS relocs that I mentioned were from testglue.o which isn't built
PIE or PIC and that's the reason for the failures to show up. Maybe
the right solu
or now in the interest of letting people be able to bootstrap and for
builds of arm-eabi to proceed I've reverted this patch thusly.
cheers
Ramana
2011-06-16 Ramana Radhakrishnan
PR target/49398
Revert.
2011-06-10 Wei Guozhi
PR target/45335
*
This seems to have triggered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
on arm-linux-gnueabi
Might well be a DUP of PR49429 but I haven't looked at it yet.
cheers
Ramana
Hi,
This fixes PR49385. We were allowing mem -> mem moves earlier. Thanks
to Revital for spotting this. Tested on qemu with arm-linux-gnueabi
cross and committed to trunk.
Cheers
Ramana
2011-06-20 Ramana Radhakrishnan
PR target/49385
* config/arm/thumb2
Joseph S. Myers wrote:
> On Mon, 20 Jun 2011, Xinyu Qi wrote:
>
>> *gcc/config/arm/elf.h: Add option -mwmmxt.
>> *gcc/config/arm/arm.opt: Same.
>
> Why? And where are the documentation updates? How does this relate to
> the existing iWMMXt options?
>
> I thought the plan (Ramana?) was to move to
> revalidated with defaults to both gnu and gnu2 style. ok?
This is OK .
Ramana
>
> nathan
> --
> Nathan Sidwell
>
>
On 21 June 2011 22:04, Janis Johnson wrote:
> This patch removes "-march=armv7-a" from four tests that pass with all
> -march values from armv4t on.
>
> OK for trunk?
>
No, that sounds like a bug - if we are generating smlaltb and friends
for v4t then the compiler is broken. This is probably beca
On 21 June 2011 22:07, Janis Johnson wrote:
> Modify three tests that require thumb support by skipping them if
> neither thumb1 nor thumb2 is supported.
>
> OK for trunk, and later for 4.6?
>
Ok
Thanks,
Ramana
On 21 June 2011 22:06, Janis Johnson wrote:
> Modify three tests that require thumb2 support to check for that rather
> than specifying an arch value that might be overridden by multilib flags.
>
> OK for trunk, and later for 4.6?
OK - this is a nice cleanup.
Ramana
>
>
> Please get approval for the target independent parts (changes to
> optabs.c) separately from a middle-end maintainer. I cannot approve
> those bits.
Can a global reviewer take a look at the non-target specific changes
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00191.html
cheers
Ramana
On 23 June 2011 22:36, Janis Johnson wrote:
> Tests gcc.target/arm/ivopts*.c add -mthumb but fail on targets without
> thumb support; skip those targets. The tests save temporary files and
> need to remove them at the end, easily done with cleanup-saved-temps.
>
> Test ivopts-6.c is the only one
On 24/06/11 01:40, Janis Johnson wrote:
Test gcc.target/arm/pr42093.c, added by Ramana, requires support for
arm_thumb2 but fails for those targets. The patch for which it was
added modified support for thumb1. Should the test instead require
arm_thumb1_ok, as in this patch?
No this is for a
On 24 June 2011 09:20, James Greenhalgh wrote:
> Apologies, I sent an incomplete ChangeLog entry.
This is OK.
cheers
Ramana
>> I introduced 2 new arm-related effective targets to accomplish this.
>> - arm_thumb2: Tests if we're compiling for thumb2.
>> - arm_nothumb: Tests if we're not compiling for any thumb.
>> I don't know how to get the same effect with the existing arm-related
>> effective
>> targets.
>
> That loo
Committed.
cheers
Ramana
2011-06-28 Ramana Radhakrishnan
* config/arm/vfp.md ("*divsf3_vfp"): Replace '+' constraint modifier
with '=' constraint modifier.
(*divdf3_vfp): Likewise.
("*mulsf3_vfp"): Likewise.
On 28 June 2011 15:20, Ramana Radhakrishnan
wrote:
> Hi,
>
> Sometime back Chung-Lin noticed that a few of the VFP patterns as below
> had the '+' constraint modifiers rather than the '=' constraint
> modifiers.
>
> I've now corrected this as foll
> OK for trunk, and for 4.6 in a few days if no problems?
>
This is OK.
Thanks,
Ramana
> Tested on arm-linux-gnueabi. OK to install?
This is OK.
cheers
Ramana
>
> It's been tested cross to ARM from x86 and also a native x86 build & test.
Cross on qemu ? You do mean a native ARM build and test :) You are
missing changelog entries in each of your patches. Could you please
reply to each of your patches with the appropriate Changelog entries ?
Thanks,
Rama
On 1 July 2011 16:57, Dr. David Alan Gilbert wrote:
>
> As per pr/48126 Michael Edwards spotted that in the case where
> the compare fails in the cmpxchg, the barrier at the end wasn't taken
> theoretically allowing a following load to float up above the load
> value compared.
Please resubmit wit
Hi Dave,
Could you split this further into a patch that deals with the
case for disabling MCR memory barriers for Thumb1 so that it
maybe backported to the release branches ? I have commented inline
as well.
Could you also provide a proper changelog entry for this that will
also help with review
On 06/07/11 11:11, Xinyu Qi wrote:
> Hi,
>
> It is the first part of iWMMXt maintenance.
>
> *config/arm/arm.c (arm_option_override):
> Enable iWMMXt with VFP. iWMMXt and NEON are incompatible. iWMMXt
> unsupported under Thumb-2 mode.
> (arm_expand_binop_builtin): Accept immediate op (with mod
2011/7/19 Jiangning Liu :
>
> I see a lot of feedbacks on other posts, but mine is still with ZERO
> response in the past 3 weeks, so I'm wondering if I made any mistake in my
> process? Who can help me?
It would be worth CC'ing the other relevant target maintainers as well
to get some feedback si
From: Ramana Radhakrishnan
Hi,
While investigating cases where we generate excessive moves
between VFP and integer registers I came across a situation
where ivopts wasn't considering the mode in which auto-increment
was allowed in this situation. Changing legitimate_address_p
wasn't
On 21/07/11 18:13, Steven Bosscher wrote:
On Thu, Jul 21, 2011 at 2:47 PM, wrote:
* tree-ssa-loop-ivopts.c (rtl.h): Include.
Please don't do this. The goal should be that GIMPLE is independent of
RTL, and almost no tree-* files include rtl.h for this reason.
Including rtl.h in tree-ss
?
cheers
Ramana
2011-07-26 Ramana Radhakrishnan
* config/arm/vfp.md ("*movdf_vfp"): Handle the VFP constraints
before the core constraints. Adjust attributes.
(*thumb2_movdf_vfp"): Likewise.
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index
Ok to commit ?
Richard was ok with this offline and the tests showed no regressions. So
I've committed this today.
Ramana
On 26 July 2011 10:02, Dr. David Alan Gilbert wrote:
>
> gcc/
> * config/arm/arm.c (TARGET_HAVE_DMB_MCR) MCR Not available in Thumb1
> but is available on armv6
`:' after (TARGET_HAVE_DMB_MCR) and something like
`Disable for Thumb1.'
instead of what's on there.
>
> /* N
On 12 April 2011 20:16, Janis Johnson wrote:
> On 04/08/2011 04:37 PM, Mike Stump wrote:
>> On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
>>> Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
>>> execution for multilibs whose hardware or simulator doesn't support that
>>> archite
On 8 April 2011 16:08, Janis Johnson wrote:
> Test gcc.target/arm/sync-1.c specifies -march=armv7-a and fails
> execution for multilibs whose hardware or simulator doesn't support that
> architecture. The test uses __sync_fetch_and_add, which GCC doesn't
> support for all arm targets. Using the
On 12/04/11 20:16, Janis Johnson wrote:
On 04/08/2011 04:37 PM, Mike Stump wrote:
On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support that
architecture.
Ideally, I
>
> OK?
OK.
Ramana
On 03/05/11 13:49, Julian Brown wrote:
Hi,
This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.
Tested manually only. OK to apply?
Ok - yes this looks almost obvious but please do a sanity regression
I have no objections to this going into 4.5 and 4.6 since it corrects
the implementation of the neon intrinsics but please check with the
release managers.
OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi?
Ok. Please allow 24 hours for an RM (cc'd) to comment since this is
On 27 April 2011 17:26, Andrew Stubbs wrote:
> On 21/04/11 16:58, Joseph S. Myers wrote:
>>
>> You need to add
>>
>> %inherit GCC_4.7.0 GCC_4.6.0
>> GCC_4.7.0 {
>> }
>
> Ok, done. Is this OK now?
I can't approve the target independent parts of this but as I said on
IRC based on a brief look I'm n
> The arm.opt change is OK, but 'Report' should stay; and it should also
> be added to the -marm case.
Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
2011-05-05 Ramana Radhakrishnan
PR target/47930
* config/arm/arm.opt (ma
>
> OK for trunk?
I have now committed this to trunk for you and will backport this to
release branches at some point in the next few days.
cheers
Ramana
>
> -- Michael
>
> gcc/
>
> 2011-05-02 Michael Hope
>
> PR pch/45979
> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define fo
Hi,
It looks like the 4.6 backport for PR target/48252 got corrupted in
some form. I've committed
this obvious fix after making sure that the build completes for a
cross to arm-linux-gnueabi.
I've kicked off a testrun just in case.
cheers
Ramana
2011-05-06 Ramana Radhakrishnan
On 17/05/11 14:10, Chung-Lin Tang wrote:
On 2011/5/13 04:26 PM, Richard Sandiford wrote:
Richard Sandiford writes:
Chung-Lin Tang writes:
My fix here simply adds 'reload_completed' as an additional condition
for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
valid, as cor
On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:
> The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
> unwind bug when using RealView and libgcc.
>
> It's an old patch that has been in CodeSourcery and Linaro toolchains
> for sometime, but somehow escaped being posted h
kport this to 4.5 branch once testing
completes. A bootstrap of trunk for C, C++ and Fortran in Thumb2 has
already completed and regression tests are on.
Cheers
Ramana
2011-03-10 Ramana Radhakrishnan
PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use '
On 11/03/11 17:21, Andrew Stubbs wrote:
On 09/03/11 16:12, Ramana Radhakrishnan wrote:
On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:
The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
unwind bug when using RealView and libgcc.
It's an old patch that has be
On 17/02/11 10:01, Chung-Lin Tang wrote:
Hi,
this PR is a case where we have a leaf function with a zero-size frame,
that calls alloca() (here through a C99 VLA).
The ARM backend recognizes the leaf-and-no-frame opportunity to save an
unneeded stack alignment. But when calling alloca(), the allo
On 31/01/11 13:27, Richard Sandiford wrote:
The v{ld,st}1q_lane_{u,s,p}8 intrinsic functions are supposed to take a range
between 0 and 15. The function is then converted to a vld1 or vst1 of one half
of the quad value. The problem is that the lane predicate doesn't account for
this, and only a
p the
issue with ICE in mem_loc_descriptor which also shows up in the
testsuite runs if the attached patch is tested alone.
Committed after testruns on qemu using cross-builds on armv7-a and
verifying that bootstrap is restored.
cheers
Ramana
2011-03-20 Ramana Radhakrishnan
PR
?
cheers
Ramana
2011-03-20 Ramana Radhakrishnan
PR target/47930
* config/arm/arm.opt (marm): Document it.
(mthumb): Reject negative variant.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 171192
On Fri, Mar 4, 2011 at 1:16 PM, Dmitry Plotnikov wrote:
> On 03/02/2011 05:27 PM, Dmitry Plotnikov wrote:
>>
>> On 02/28/2011 02:49 AM, Ramana Radhakrishnan wrote:
>>>
>>
> There was a mistake in the patch. According to documentation vshl should
> have .i suf
On 24/03/11 09:06, Ira Rosen wrote:
Hi,
This patch implements TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES for ARM NEON.
Regtested on arm-linux-gnueabi.
OK for trunk?
This is OK for trunk if there are no regressions.
cheers
Ramana
Thanks,
Ira
ChangeLog:
* config/arm/arm.c (arm_au
Tested on arm-linux-gnueabi. OK to install?
Thanks for this - yes , this is ok for trunk. It fixes PR43590 as well.
cheers
Ramana
Richard
gcc/
* config/arm/neon.md (neon_vld3qa, neon_vld4qa): Remove
operand 1 and reshuffle the operands to match.
(neon_vld3, neon_
Hi Carrot,
On 26/03/11 15:14, Carrot Wei wrote:
Index: arm.md
===
--- arm.md (revision 171337)
+++ arm.md (working copy)
@@ -7115,7 +7115,18 @@
"@
cmp%?\\t%0, %1
cmn%?\\t%0, #%n1"
- [(set_attr "conds" "set")
Hi Carrot,
How about adding an alternative only enabled for T2 that uses the `l'
constraint and inventing new constraints for some of the constant values
that are valid for 16 bit instructions since the `I' and `L' constraints
have different meanings depending on whether TARGET_32BIT
the negative of that option ?
If not, we should then consider adding a RejectNegative to that option.
cheers
Ramana
--
Ramana Radhakrishnan
The patch was tested on arm qemu without regression, OK for install?
Ok if no regressions.
cheers
Ramana
thanks
Carrot
ChangeLog:
2011-04-01 Wei Guozhi
PR target/47855
* config/arm/arm.md (arm_cmpsi_insn): Compute attr "length".
(arm_cond_branch): Likewise.
asses.
cheers
Ramana
2011-04-06 Ramana Radhakrishnan
* gcc.target/arm/pr43920-1.c: Fix accidental duplication.
Index: gcc/testsuite/gcc.target/arm/pr43920-1.c
===
--- gcc/testsuite/gcc.target/arm/pr43920-1.c(rev
Is this updated version (
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00058.html ) ok for trunk?
I think you accidentally applied the patch twice and committed it. Yeah
unfortunately there is no equivalent of git clean -f -d in svn unless
you write something up with svn status and some shel
On 07/04/11 12:08, Carrot Wei wrote:
On Thu, Apr 7, 2011 at 5:31 PM, Richard Sandiford
wrote:
Hi Carrot,
Sorry if this has already been reported, but the patch breaks bootstrap
of arm-linux-gnueabi (or cross builds with --enable-werror). The problem
is that this...
uses a statement expressi
On 07/04/11 08:42, Ira Rosen wrote:
Hi,
This patch makes both outputs of neon_vzip/vuzp/vtrn_internal
explicitly dependent on both inputs, preventing incorrect
optimization:
for
(a,b)<- vzip (c,d)
and
(e,f)<- vzip (g,d)
CSE decides that b==f, since b and f depend only on d.
Tested on arm-linux-
onst_int 0)))
- (const_int 2)
- (const_int 4)))]
+ (symbol_ref "arm_attr_length_push_multi (operands[2], operands[1])"))]
)
(define_insn "stack_tie"
On Thu, Apr 7, 2011 at 7:30 PM, Ramana Radhakrishnan
wrote:
On 07/04/11 12:08, Carrot Wei wrote:
On 8 April 2011 09:52, Carrot Wei wrote:
> Sorry, which pattern in thumb2.md?
Sorry, I meant to say push_multi in arm.md . Not enough coffee yet this morning.
cheers
Ramana
>
> thanks
> Carrot
>
> On Fri, Apr 8, 2011 at 4:35 PM, Ramana Radhakrishnan
> wrote:
>> On
On 08/04/11 10:57, Carrot Wei wrote:
Hi
This is the second part of the fixing for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
This patch contains the length computation for insn patterns "*arm_movqi_insn"
and "*arm_addsi3". Since the alternatives and encodings are much more complex,
the
s and
it is interesting to note that this hasn't been caught in such a long time.
Testing in progress . Ok to commit to all release branches ?
cheers
Ramana
2011-04-11 Ramana Radhakrishnan
PR target/48090
* config/arm/arm.md (*arm_negdi2): Fix early clobber constraints.
On Fri, Oct 4, 2024 at 9:25 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
> 116444]' introduced regressions with arm targets that used 'noce' before.
> This is because it would approve all noce optimisations without using
> the def
On Fri, Sep 27, 2024 at 2:11 PM Andre Vieira (lists)
wrote:
>
>
>
> On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
> >
>
> >> +/* Helper function to determine whether SEQ represents a sequence of
> >> + instructions representing the Ar
On Thu, Sep 5, 2024 at 4:30 PM Victor Do Nascimento
wrote:
>
>
> Changes from previous revision:
>
> As was done for the equivalent aarch64 patch, we rework this patch to do away
> with
> mission creep, keeping changes as simple as possible.
>
> We thus remove the `gimple_fold_builtin' changes th
On Thu, Sep 12, 2024 at 8:42 PM Richard Earnshaw wrote:
>
> This short patch series adds the ability to unset the -mcpu and -march
> options on the Arm port. This helps to avoid ambiguities and warnings
> if, for some reason, the compiler flags need to be overridden.
>
> The main intent of this i
> On 25 Sep 2024, at 7:38 PM, Andre Vieira (lists)
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> This patch restores missed optimizations for armv8.1-m.main targets that
> were missed when the generation of csinc, csinv and csneg were enabled
> or the sa
On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> fl
> On 19 Nov 2024, at 4:18 PM, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
>> -Original Message-
>> From: Andrew Pinski
>> Sent: Friday, November 15, 2024 7:16 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
On Tue, Mar 4, 2025 at 11:47 PM Wilco Dijkstra wrote:
>
> Hi Kyrill,
>
> > This restriction should be documented in invoke.texi IMO.
> > I also think it would be more user friendly to warn them about the
> > incompatibility if an explicit -moutline-atomics option is passed.
> > It’s okay though t
On Fri, Mar 7, 2025 at 11:07 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard,
> >
> >>> Basically the small and large model are fundamentally incompatible. The
> >>> infamous
> >>> "dumb linker" approach means it doesn't try to sort sections, so an ADRP
> >>> relocation
>
On Thu, May 22, 2025 at 11:09 AM Ramana Radhakrishnan
wrote:
>
> On Wed, May 7, 2025 at 6:18 PM Richard Earnshaw wrote:
> >
> >
> > The header file for the Arm implementation of mmintrin.h was changed in
> > GCC-15
> > to disable access to the intrinsics.
On Wed, May 7, 2025 at 6:18 PM Richard Earnshaw wrote:
>
> The flattened logic of these functions and the complexity of the
> numerous clauses makes it very difficult to understand what's written
> in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
> laid out with the correct for
On Wed, May 7, 2025 at 6:18 PM Richard Earnshaw wrote:
>
>
> The header file for the Arm implementation of mmintrin.h was changed in GCC-15
> to disable access to the intrinsics. This patch removes the internal code
> as well.
>
> We still allow -mcpu/-march options for the wmmx cpus, but they ar
On Mon, May 12, 2025 at 11:50 AM Richard Earnshaw wrote:
>
> The flattened logic of these functions and the complexity of the
> numerous clauses makes it very difficult to understand what's written
> in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
> laid out with the correct f
Hi Lance,
Thanks for your contribution - looks like your first one to GCC ?
The patch looks good to me, though it should probably go through a
full test suite run on arm-linux-gnueabihf and get a ChangeLog - see
here for more https://gcc.gnu.org/contribute.html#patches.
This is probably small en
On Thu, Oct 8, 2020 at 10:22 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The arm target hook for divmod wasn't prepared to handle constants passed to
> the function.
>
> Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> 2020-10-08 Jakub Jelinek
>
>
Nick Clifton
arm port Richard Earnshaw
-arm port Ramana Radhakrishnan
+arm port Ramana Radhakrishnan
arm port Kyrylo Tkachov
avr port Denis Chertykov
bfin port Jie
This is OK
Ramana
On 22/09/2021, 09:45, "Przemyslaw Wirkus" wrote:
Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
flag for -mcpu option.
See: https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52-plus
OK for master?
gcc/ChangeLog:
2021-09-22
Wirkus
Cc: Ramana Radhakrishnan ,
gcc-patches@gcc.gnu.org , Richard Earnshaw
Subject: Re: [PATCH][GCC] arm: add armv9-a architecture to -march
You can't make an omelette without breaking eggs, as they say. New
architectures need new assemblers.
However, I wonder if there's anything in
2021 at 22:03
To: Qing Zhao
Cc: Ramana Radhakrishnan ,
linux-harden...@vger.kernel.org , kees Cook
, Keith Packard ,
thomas.preudho...@celest.fr ,
adhemerval.zane...@linaro.org , Richard
Sandiford , gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v4 1/1] [ARM] Add support for TLS register based
On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes t
On Thu, Aug 20, 2020 at 3:31 PM Joe Ramsay wrote:
>
> Hi Ramana,
>
> Thanks for the review.
>
> On 18/08/2020, 18:37, "Ramana Radhakrishnan"
> wrote:
>
> On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
> >
> > From: Joe Ramsay
&g
On Mon, Aug 17, 2020 at 7:42 PM Dennis Zhang wrote:
>
>
> Hi all,
>
> This patch enables MVE vsub instructions for auto-vectorization.
> It adds RTL templates for MVE vsub instructions using 'minus' instead of
> unspec expression to make the instructions recognizable for vectorization.
> MVE targe
On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
wrote:
>
> armv8-m.base (cortex-m23) has the movt instruction, so we need to
> disable the define_split to generate a constant in this case,
> otherwise we get incorrect insn constraints as described in PR94538.
>
> We also need to f
On Fri, Aug 21, 2020 at 2:28 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes t
On Mon, Aug 24, 2020 at 4:35 PM Christophe Lyon
wrote:
>
> On Mon, 24 Aug 2020 at 11:09, Christophe Lyon
> wrote:
> >
> > On Sat, 22 Aug 2020 at 00:44, Ramana Radhakrishnan
> > wrote:
> > >
> > > On Wed, Aug 19, 2020 at 10:32 AM
1301 - 1400 of 1425 matches
Mail list logo
