||clyon at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #7 from Christophe Lyon ---
Fixed on trunk (gcc-16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
--- Comment #3 from Christophe Lyon ---
(In reply to Iain Buclaw from comment #2)
> @Christophe, I can only assume this is fixed, but have no way to test.
It seems so, has the test been renamed? I can see this with recent trunk:
PASS: libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119556
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
g:78e0cf06c818e6293d36e52ad7a96bd9e7953c06 enabled gcc.target/arm/short-vfp-1.c
but all the scan-assembler directives fail.
In fact, it has (would have) always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119550
Christophe Lyon changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: jason at redhat dot com
Target Milestone: ---
Target: arm aarch64
The test introduced by g:b360d4aafc1356386313c7392f7444b3fc356681 fails on arm
and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #22 from Christophe Lyon ---
Bootstrap on arm-linux-gnueabihf passes, 'make check' too.
Sorry for the delay, I was trying to understand an ICE
gcc.target/arm/mve/general/preserve_user_namespace_1.c after I bootstrapped
with your pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #18 from Christophe Lyon ---
Thanks for your patch!
I can confirm your comment #16, bootstrap in progress on an arm-linux-gnueabihf
machines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
--- Comment #3 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #14 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119110
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||clyon at gcc dot gnu.org
--- Comment #19 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676812.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
--- Comment #8 from Christophe Lyon ---
We currently have:
struct cpu_vec_costs arm_default_vec_cost = {
1,/* scalar_stmt_cost. */
1,/* scalar load_cost. */
1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
--- Comment #7 from Christophe Lyon ---
The slp2 dump says:
[...]
pr116032.c:6:8: note: * Analysis succeeded with vector mode V4SI
pr116032.c:6:8: note: SLPing BB part
pr116032.c:6:8: note: Costing subgraph:
pr116032.c:6:8: note: node 0xb47b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117712
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 60600 [details]
> gcc15-pr117712.patch
>
> Untested fix.
> Though, I wonder what prevents arbitrarily complex rtxes that force_operand
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
--- Comment #6 from Christophe Lyon ---
I mean in this case CONST_VECTOR already has a cost of 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117712
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118715
--- Comment #8 from Christophe Lyon ---
I've opened a linker bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=32659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118715
Christophe Lyon changed:
What|Removed |Added
Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
--- Comment #4 from Christophe Lyon ---
For the warning in
FAIL: gcc.target/arm/pr112337.c (test for excess errors)
this is caused by how we define __fp16, see
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670563.html
https://gcc.gnu.o
||2025-02-04
Status|UNCONFIRMED |ASSIGNED
CC||clyon at gcc dot gnu.org
--- Comment #6 from Christophe Lyon ---
>From the linker side, I think the problem is that the first time
using_thumb_only() is called,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
--- Comment #6 from Christophe Lyon ---
Looking at dumps when compiling for cortex-m7 and cortex-m55, I noticed a
difference in the first gimple trace (pr82692.c.007t.gimple).
For m7, we have:
_1 = x u> 0.0;
_2 = ~_1;
_3 = x u<= 1.0e+0;
_4 = ~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
--- Comment #4 from Christophe Lyon ---
(In reply to Torbjorn SVENSSON from comment #3)
lr @ 69[c=8 l=4] *thumb2_return
>
> The above was extracted from compiling using:
> arm-none-eabi-gcc pr82692.c -mthumb -march=armv7e-m+fp.dp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #9 from Christophe Lyon ---
The patch I proposed for PR117814
(https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674281.html) is not
sufficient to fix this problem.
IIUC the current multilib definitions (from t-rmprofile) map
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
--- Comment #7 from Christophe Lyon ---
Besides fixing the ICE, the patch I proposed in c#5 changes the codegen for
armv8_2-fp16-move-2.c, which is compiled with
-marm -mcpu=unset -march=armv8.2-a+fp16
from:
test_select:
vcvtb.f32.f16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
--- Comment #8 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673791.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
--- Comment #5 from Christophe Lyon ---
The test has:
/* { dg-require-effective-target arm_thumb2_ok_no_arm_v8_1_lob } */
since commit g:d2ed233cb940aa3eecc163d98b47979dd81dbc0a
with this comment: "Do not run when generating low loop overhead."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #8 from Christophe Lyon ---
Indeed, the problem is that +mve does not enable the floating-point extension,
as opposed to +mve.fp, which means that arm_fp16_inst is false (in arm.cc /
arm_option_reconfigure_globals) so arm_fp16_format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
mponent: d
Assignee: ibuclaw at gdcproject dot org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
In our CI with highly parallel builds, we have noticed random failures in the
'd' front-end, with errors like:
mv: cannot stat 'd/.deps/package.TPo': No such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118332
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
#include
uint32x4_t first(uint32x4x4_t a) { return a.val[0]; }
compiled with -mcpu=cortex-m55 -mfloat-abi=hard -mfpu=auto fails w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118176
Christophe Lyon changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #3 from Christophe Lyon ---
> It might be helpful to see the dissassembled code of
> sync/atomic_test.TestNilDeref..func30.
Sorry for the naive question: where can I find it?
In my build tree, I have:
armv8l-unknown-linux-gnueab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #1 from Christophe Lyon ---
libgo.log says:
unexpected fault address 0x1e08e
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x1e08e pc=0x0]
goroutine 215 [running]:
runtime.dopanic__m
/home/christophe.lyon/src/Li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #9 from Christophe Lyon ---
I have opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152 about the
sync/atomic failure.
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
libgo's sync/atomic has been reported to fail for a long time on arm, and I
have bisected this to com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118131
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118131
--- Comment #1 from Christophe Lyon ---
This is because arm.cc:arm_attr_length_move_neon() does not handle the new MVE
struct modes, which correspond to OImode and XImode.
Adding them leads to a crash later because in neon.md we have
(define_sp
://linaro.atlassian.net/browse/GNU-1467
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
As reported
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: arm
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
--- Comment #8 from Christophe Lyon ---
Sorry for the delay: it took me a while to reproduce the problem manually,
while it does show up in CI.
The problem does not happen when I rebuild a full toolchain (trunk binutils +
trunk glibc + trunk gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #5 from Christophe Lyon ---
Note that the test passed before commit r15-5997-g75e7d1600f4785 , which was
bisected by the CI.
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: vmakarov at redhat dot com
Target Milestone: ---
Target: arm
After commit g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
/browse/GNU-1445
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: clyon at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com
Target Milestone: ---
Target
://linaro.atlassian.net/browse/GNU-1444
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: jakub at redhat dot com
Target Milestone
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: azoff at gcc dot gnu.org
Target Milestone: ---
Since commit
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117958
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
After commit r15-4734-g63b6967b06b538
we have noticed several regressions on arm:
on arm-none-eabi and arm-none-linux-gnueabihf:
Running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As described in https://bugs.linaro.org/show_bug.cgi?id=6058, this short code
fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117600
--- Comment #1 from Christophe Lyon ---
Forcing -Werror was a request/decision:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664797.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #39 from Christophe Lyon ---
A bit more context:
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
The section about predicates uses the word 'lanes' and says 'When calling a
predica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117407
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #12 from Christophe Lyon ---
Just noticed this in config.log:
configure:16789: checking for C locale to use
configure:16793: result: generic
so yeah, there's "some info" that --enable-clocale=gnu did not have the
expected effect :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #7 from Christophe Lyon ---
Looking at my build dir, I can see that libstdc++ build system makes symlinks
to time_members.cc in the build dir.
And in my case, all these links point to
libstdc++-v3/config/locale/generic/time_members.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #5 from Christophe Lyon ---
Looking at newlib's nl_langinfo_l
(https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/locale/nl_langinfo.c;h=4477d833bec18572265df8e9b8914af695fab8bb;hb=HEAD)
at quick glance it seems it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #2 from Christophe Lyon ---
The additional debug output with your patch is:
Wide D_T_FMT for C locale:
eofbit: 0 failbit: 0 badbit: 0
22_locale/time_get/get/wchar_t/5.cc:29: int main(): Assertion 'err ==
std::ios::eofbit' failed.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: jwakely.gcc at gmail dot com
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
Created attachment 59342
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #18 from Christophe Lyon ---
Sorry, no, this is not the cause of the problem (actually musttail7.c also
fails in gcc.log).
I looked into this, and it's a bit tricky
in arm_function_ok_for_sibcall() (from arm.cc), we have:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #15 from Christophe Lyon ---
(In reply to andi from comment #14)
> The test relies on the
>
> gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
Are you sure?
musttail7.c has:
/* { dg-do compile { target { mustta
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since r15-3794-g2c04f175de4f39, we noticed this
|---
CC||clyon at gcc dot gnu.org
--- Comment #13 from Christophe Lyon ---
As of r15-3812-g4700ad1c78ccd7, musttail7.c still fails on arm-eabi with
default configuration / test flags:
FAIL: c-c++-common/musttail7.c -std=c++11 (test
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since commit gcc-15-3735-g664e0ce580a8, we have noticed failures in
gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260
--- Comment #3 from Christophe Lyon ---
Thanks for the additional information, indeed in our CI we do not run
validations for several "variations", so it's not surprising this case is not
handled very well.
So you suggest having one manifest pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
||clyon at gcc dot gnu.org
Status|ASSIGNED|RESOLVED
--- Comment #23 from Christophe Lyon ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Bug 115635 depends on bug 115661, which changed state.
Bug 115661 Summary: [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu
since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #16 from Christophe Lyon ---
(In reply to Richard Biener from comment #15)
> OK, looking the fix was only half complete. Can you try
It works with this, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #14 from Christophe Lyon ---
Created attachment 58522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit
Wrong code after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #13 from Christophe Lyon ---
Yes it breaks at the same point, again we are returning an uninitialized value.
Adding annotate asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #11 from Christophe Lyon ---
Created attachment 58520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit
vect dump broken after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #2 from Christophe Lyon ---
Created attachment 58431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit
vect dump OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #3 from Christophe Lyon ---
Created attachment 58432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit
vect dump broken
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Created attachment 58428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58428&action=edit
Code generated bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #1 from Christophe Lyon ---
Created attachment 58429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit
Wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since gcc-15-276-gbed6ec161be (g:bed6ec161be8c5ca2f24195900ce3c9b81c3e141) we
have noticed a regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #32 from Christophe Lyon ---
Created attachment 58110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit
patch v2
Here is another patch proposal along the lines of what you suggest in #c24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #30 from Christophe Lyon ---
> ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
> pr114801.c -mthumb -O2 -da
Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
1 - 100 of 1212 matches
Mail list logo
