https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #26 from Christophe Lyon ---
Created attachment 49171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49171&action=edit
v7 intrinsics not supported by the aarch32/arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #25 from Christophe Lyon ---
Created attachment 49170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49170&action=edit
a64 intrinsics not supported by the aarch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #23 from Christophe Lyon ---
Created attachment 49168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49168&action=edit
v7 intrinsics not supported by the aarch64 target
Update 2020-09-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #24 from Christophe Lyon ---
Created attachment 49169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49169&action=edit
a32/a64 intrinsics not supported by the aarch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #22 from Christophe Lyon ---
Applying the recipe from comment #6, the current list of duplicates is:
New ones:
2 vcmla_laneq_f16
2 vcmla_rot180_laneq_f16
2 vcmla_rot270_laneq_f16
2 vcmla_rot90_laneq_f16
Known,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #21 from Christophe Lyon ---
Created attachment 49167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49167&action=edit
Full list of intrinsics documented for a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #20 from Christophe Lyon ---
Created attachment 49166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49166&action=edit
Full list of intrinsics documented for a32/a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #19 from Christophe Lyon ---
Created attachment 49165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49165&action=edit
Full list of intrinsics documented for v7/a32/a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #18 from Christophe Lyon ---
The list at
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
has a new format (the list is split in 146 pages, I couldn't find how to get
the list on a single page). So I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #17 from Christophe Lyon ---
Created attachment 49162
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49162&action=edit
Full Neon intrinsics list as of 2020-09-01.
Full Neon intrinsics list as of 2020-09-01.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
--- Comment #4 from Christophe Lyon ---
That's what I replied in the original PR94538, but Wilco said the best option
was to turn off switch tables:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538#c14
See also another comment from him:
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96579
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2020-08-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
--- Comment #2 from Christophe Lyon ---
Send patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552798.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
--- Comment #1 from Christophe Lyon ---
This is related to comments 10,11,14,15 and 16 in the original PR94538.
In comment 14, Wilco suggested: "The best option is to do the same as
Cortex-M3: just switch off branch tables altogether and fall ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The gcc.target/arm/pr43920-c testcase fails since svn r228175 / git
f11a7b6d57f6fcba1bf2e5a0403dc49120195320 (r6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #21 from Christophe Lyon ---
I filed PR96767, PR96768, PR96769, PR96770 to track the enhancements discussed
here.
The ICE is now fixed in trunk.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces suboptimal code for relocations
with small offset for thumb-1.
int arr
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces switch tables for thumb-1.
int f3 (void) { return 0x1100; }
int f3_2 (void
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in PR94538, -mpure-code produces switch tables for thumb-1.
int f2 (int x, int y)
{
switch (x)
{
case 0: return y + 0;
case 1: return y + 1;
case
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As described in PR94538, -mpure-code produces suboptimal code for thumb-1 CPUs.
int x;
int f1 (void) { return x; }
Compiled with -O2 -mpure-code,
-mcpu=cortex-m0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94531
--- Comment #1 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #0)
> I've noticed that gcc.target/arm/its.c fails when targetting
> cortex-m3 or m33, but that's probably true with all cortex-m versions.
>
Since I have extendin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
||aarch64 arm
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Seen also on aarch64 and arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375
--- Comment #4 from Christophe Lyon ---
(In reply to Andrea Corallo from comment #3)
> "clyon at gcc dot gnu.org" writes:
> > Hi,
>
> Hi,
>
> > It does fix the FAIL, thanks.
>
> Thanks for testing i
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r13cdbb6a97c3d853cd380e5a03be8e0d35966c1e, I've noticed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375
--- Comment #2 from Christophe Lyon ---
(In reply to akrl from comment #1)
> Created attachment 48968 [details]
> pr96375 lob tests patch
>
> Hi Christophe,
>
> The following patch does the job for me. Would you double check is
> effective for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96376
--- Comment #1 from Christophe Lyon ---
Bisect identified commit g30fdaead5b7880c4e9f140618e26ad1c545642d5
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed regressions on target armeb-none-linux-gnueabihf --with-mode arm
--with-cpu cortex-a9 --wit
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since these new tests were introduced, I've noticed that they fail on some
configurations.
For instance, with target arm-none-
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-2012-gd2ed233cb940aa3eecc163d98b47979dd81dbc0a, I've noticed that
FAIL: gcc.target/arm/ivopts.c object-size text <= 20
depending on how GCC is configur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96136
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
gcc.dg/vect/slp-46.c fails on aarch64 since it was introduced.
In the logs I can see:
PASS: gcc.dg/vect/slp-46.c execution test
gcc.dg/vect/slp-46.c: pattern found 0 times
FAIL: gcc.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r11-1914-g760df6d296b8fc59796f42dca5eb14012fbfa28b, I've noticed an ICE
while building glibc-2.29 when GCC is configured --target
arm-none-linux-gnue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #22 from Christophe Lyon ---
Not sure if we can close this PR: I have only implemented a part of what we
discussed here. GCC now emits a warning so the user can take action to make
sure his code is correct/correctly generated, but GCC
||arm*-linux-gnueabihf
CC||clyon at gcc dot gnu.org
--- Comment #3 from Christophe Lyon ---
I see it on arm-none-linux-gnueabihf too
(--with-cpu cortex-a9 --with-fpu neon-fp16 for instance)
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3
I have noticed:
FAIL: gcc.target
: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
The new testcase pr95690.f90 fails on arm and aarch64 (and powerpc, s390
accordng to gcc-testresults).
compiler exited with status 1
FAIL: gfortran.dg/pr95690.f90 -O (test for errors, line 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95858
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95745
--- Comment #6 from Christophe Lyon ---
(In reply to Martin Liška from comment #4)
> Ok, can I test it with a x86_64-linux-gnu cross compiler?
Yes, that's what I am using.
Target: arm-none-linux-gnueabi
Configured with: /configure --target=arm-
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
I see the same thing on some arm targets:
arm-none-linux-gnueabihf --with-cpu=cortex-a5
arm-none-eabi -mcpu=cortex-m[034]
but for instance arm-none-linux-gnueabihf --with-cpu=cortex-a9 works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95745
--- Comment #3 from Christophe Lyon ---
I still see it with r11-1521-gaae80e833d2826fc0afe7ff1704d2ab0f4607c5a
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f I have noticed that
O3-pr85794.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95633
--- Comment #6 from Christophe Lyon ---
(In reply to Richard Biener from comment #3)
> I cannot reproduce the arm failure, neon-fp1 doesn't seem to exist and any
> combo of -mcpu=cortex-a9 and -mfpu=... does not ICE for me.
Sorry, that was a cut
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
I've noticed regressions since
r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0:
on aarch64:
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r11-830 (g:85bce484d37fdda9c7eadb9bdcdb1ded891462bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95421
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since g:e31cd607e999ca6ab47b7e65a7045b1594e4fba4
I've noticed
gcc.dg/vshift-5.c (internal compiler
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since gc0e27f72358794692e367363940c6383e9ad1e45, I've noticed that
gcc.dg/vect/bb-slp-pr95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362
Christophe Lyon changed:
What|Removed |Added
Summary|[11 regression] pr34457-1.c |[11 regression] pr34457-1.c
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
since ga746f952abb78af9db28a7f3bce442e113877c9c, I've noticed that
pr34457-1.c fails on arm and aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95273
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #19 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #8)
> Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html
>
> This is a simple improvement, hopefully simple enough for stage 4, yet
> us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #18 from Christophe Lyon ---
> I'm working on this, and just realized that this also means saving FPSR. It
> seems there's no support for that yet in arm.md (unlike aarch64.md), am I
> missing something?
>
Sorry, I see it's called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #17 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function di
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
I've noticed that
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects scan-tree-dump-times
vect "p
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
After r11-165-geb72dc663e9070b281be83a80f6f838a3a878822, I've noticed that
scalar-by-va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #16 from Christophe Lyon ---
Another potential issue just came to my mind: what if the IRQ handler is
compiled with -mfloat-abi=soft but calls a function compiled with
-mfloat-abi=softfp? We have no way to guess that the FP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #15 from Christophe Lyon ---
> Well obviously that won't work. But if you build the interrupt routine with
> a d16 system and then call a function from it that requires d32 then that
> should still work if running on a d32 CPU.
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #13 from Christophe Lyon ---
> > Why do we need a library function for that? It would have to be special with
> > the stack: push FP registers, but do not restore SP, so that the dual
> > restore function can pop them and restore SP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #11 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #9 from Christophe Lyon ---
> My initial thoughts are along the lines of...
> Only try to save FP registers that this function directly clobbers.
What's the point of saving these if a callee clobbers other registers?
Shouldn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
Christophe Lyon changed:
What|Removed |Added
Known to work||9.2.0
--- Comment #18 from Christophe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
--- Comment #3 from Christophe Lyon ---
(In reply to vvinayag from comment #2)
> Sorry for the late reply.
> The tests appear to pass when I invoke them locally. They only failed as
> part of our buildbot run tests. It could be a glitch in our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002
Christophe Lyon changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
--- Comment #8 from Christophe Lyon ---
Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html
This is a simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #6 from Christophe Lyon ---
If we consider the initial testcase, it doesn't clobber any FP register
directly, but the compiler inserts a call to memcpy which does.
So IIUC your 1st suggestion, it would mean:
- save no FP register in
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
The new gcc.dg/pr94780.c test causes an ICE on aarch64:
/gcc/testsuite/gcc.dg/pr94780.c: In function 'foo':
/gcc/testsuite/gcc.dg/pr94780.c:8:1: internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #3 from Christophe Lyon ---
Maybe we could
- save the VFP registers as needed by default
- emit a warning "IRQ handler 'foo' saves VFP registers because it is not a
leaf function. If you know none of the callees will clobber the VFP r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #2 from Christophe Lyon ---
I have a preliminary patch which generates:
vpush.64{d0, d1, d2, d3, d4, d5, d6, d7}
vpush.64{d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26,
d27, d28, d29, d30, d31}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #1 from Christophe Lyon ---
clang has implemented a warning for this case:
https://reviews.llvm.org/D28820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
As described in https://bugs.linaro.org/show_bug.cgi?id=5614:
IRQ implementation when using __attribute__ (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
--- Comment #26 from Christophe Lyon ---
For what CPU did you configure GCC?
With today's trunk I still see the same code as in comment #24.
I can get the same code as you have in comment #25 if I force -mcpu=cortex-a9.
The bug report is about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94604
--- Comment #2 from Christophe Lyon ---
I think this is provided by arm_acle.h:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/arm_acle.h;h=6b08ffd4174c8d829fe5730f99cd8f28e300afab;hb=HEAD
You can see that saturating and DSP intrins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #15 from Christophe Lyon ---
(In reply to Wilco from comment #14)
> (In reply to Christophe Lyon from comment #11)
> > (In reply to Wilco from comment #10)
>
> > Right, but the code is functional.
>
> It doesn't avoid the literal lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #12 from Christophe Lyon ---
I've posted a patch to fix the regression for your f3() examples:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543993.html
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
The recent fix for PR94426 (g8d213cbbe1856e6088282aa0076646cec694b030)
causes regressions on arm:
g++.dg/lto/pr83720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #11 from Christophe Lyon ---
(In reply to Wilco from comment #10)
>
> For example:
>
> int x;
> int f1 (void) { return x; }
>
> with eg. -O2 -mcpu=cortex-m0 -mpure-code I get:
>
> movsr3, #:upper8_15:#.LC1
> ls
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that gcc.target/arm/thumb2-cond-cmp-*.c fail when targeting
cortex-M CPUs.
For thumb2-cond-cmp-1.c, the code generated at svn r196196 for cortex-m3 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94576
Christophe Lyon changed:
What|Removed |Added
Target|aarch64 |arm
Summary|Regression buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #8 from Christophe Lyon ---
> Adding Christophe. I'm thinking the best approach right now is to revert
> given -mpure-code doesn't work at all on Thumb-1 targets - it still emits
> literal pools, switch tables etc. That's not pure co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94576
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82038
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56550
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that gcc.target/arm/acle/cde.c fails on
armeb-none-linux-gnueabihf.
gcc.target/arm/acle/cde.c -O1 check-function-bodies test_cde_cx1da
gcc.targe
||clyon at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Christophe Lyon ---
(In reply to Ravaz from comment #0)
[...]
> The instruction at 0x810c forces the address used for the ldrd to be
> alligned to an 8 bytes boundar
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that gcc.target/arm/its.c fails when targetting
cortex-m3 or m33, but that's probably true with all cortex-m versions.
The code generated at r206697 (just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #7 from Christophe Lyon ---
Created attachment 48185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48185&action=edit
qemu execution trace
401 - 500 of 1133 matches
Mail list logo
