||clyon at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Christophe Lyon ---
I am able to reproduce the failure with the same commit mentioned by Maxim in
comment #3. Using a more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #8 from Christophe Lyon ---
I also tried to run the program under QEMU, it works (doesn't crash)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #10 from Christophe Lyon ---
I checked the stack settings on the ARMv7 and ARMv8 machines:
ARMv7: beced000-bed0e000 rw-p 00:00 0 [stack]
ARMv8: fff12000-fff33000 rw-p 00:00 0 [stack]
In both cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
I've noticed this ICE while building GDB with recent GCC trunk, it appeared
between: r10-7336 and r10-7346
x86_64-unknown-linux-gnu-g++ -g -O2 -c ada-la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94339
--- Comment #2 from Christophe Lyon ---
Created attachment 48123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48123&action=edit
ada-lang.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that the fix for PR90332 caused a regression on aarch64:
FAIL: gcc.dg/vect/pr92420.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
--- Comment #12 from Christophe Lyon ---
> Can you open a new bugreport?
Sure, I filed PR94401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401
--- Comment #2 from Christophe Lyon ---
The defaults are OK (either native or cross aarch64)
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that when GCC is configured --target arm-none-abi
--with-mode=thumb --with-cpu=cortex-m33, the cmse-15.c test fails:
FAIL: gcc.target/arm/cmse/cmse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
--- Comment #3 from Christophe Lyon ---
I also checked that arm_handle_cmse_nonsecure_call correctly duplicates the
type.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r10-7491, I've noticed a regression with an ICE:
FAIL: gcc.target/aarch64/sve/pr87815.c -march=armv8.2-a+sve (internal compiler
error)
/gcc/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #5 from Christophe Lyon ---
Created attachment 48183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48183&action=edit
executable asm from objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #6 from Christophe Lyon ---
Created attachment 48184
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48184&action=edit
GCC passes dumps
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
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
||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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56550
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
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=82038
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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=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
Target|aarch64 |arm
Summary|Regression buil
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=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
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 #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
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=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=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
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=94763
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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=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=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 #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
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Commen
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
--- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
|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
Status|NEW |RESOLVED
Resolution|---
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=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=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=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 #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=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 #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 #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
: 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
: 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
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
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 #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=95273
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
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=95362
Christophe Lyon changed:
What|Removed |Added
Summary|[11 regression] pr34457-1.c |[11 regression] pr34457-1.c
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
: 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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706
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: ---
Hi,
Since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f I have noticed that
O3-pr85794.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95745
--- Comment #3 from Christophe Lyon ---
I still see it with r11-1521-gaae80e833d2826fc0afe7ff1704d2ab0f4607c5a
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 #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-
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=95720
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
: 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
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
||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)
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
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=96109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
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=96136
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
: 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
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-
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96376
--- Comment #1 from Christophe Lyon ---
Bisect identified commit g30fdaead5b7880c4e9f140618e26ad1c545642d5
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
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 #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
||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=94681
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
: 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
: 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
: 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
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
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: 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
1 - 100 of 1214 matches
Mail list logo
