https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
--- Comment #7 from Christophe Lyon ---
While we could adjust the test to avoid the warning, this would hide a bug: we
should not really emit a warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117013
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119556
Bug ID: 119556
Summary: gcc.target/arm/short-vfp-1.c fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119550
Christophe Lyon changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119499
Bug ID: 119499
Summary: g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
Christophe Lyon changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118715
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118477
Bug ID: 118477
Summary: Race condition in 'd' Make-lang.in
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
A
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118332
Bug ID: 118332
Summary: MVE no longer exposes tuple members as 'val'
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
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
--- C
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
Bug ID: 118152
Summary: libgo sync/atomic fails since
g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1 on arm
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118131
Bug ID: 118131
Summary: [15 regression] ICE in gcc.c-torture/execute/loop-13.c
after g:4f4e13dd235bba9c706948a3ecb3e530dd68aad1
Product: gcc
Version: 15.0
URL: https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118062
Bug ID: 118062
Summary: [15 regression]
c-c++-common/torture/vector-compare-1.c fails on arm /
MVE after gcc-15-5317-gf40010c198f
Product: gcc
Version: 15.0
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
Bug ID: 117999
Summary: libgo regressions on arm after
g:75e7d1600f47859df40b2ac0feff5a71e0dbb040
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Bug ID: 117997
Summary: libgo regressions on aarch64 after
g:4d2b9202fe94c54e63fb07d48293a78da3d82532
Product: gcc
Version: 15.0
URL: https://linaro.atlassian.net/bro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117995
Bug ID: 117995
Summary: Regression in libphobos tests on arm after
g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa
Product: gcc
Version: 15.0
URL: https://linaro.atlassian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117994
Bug ID: 117994
Summary: New failures on arm since
g:f55cc57c6e3bcb36279682254b9b532049ff3f9d
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117958
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
Bug ID: 117814
Summary: arm/MVE: regressions after r15-4734-g63b6967b06b538
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117792
Bug ID: 117792
Summary: ICE in tsubst_template_args
Product: gcc
Version: 15.0
URL: https://bugs.linaro.org/show_bug.cgi?id=6058
Status: UNCONFIRMED
Severity: norma
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
Bug ID: 117135
Summary: 22_locale/time_get/get/wchar_t/5.cc fails on arm since
gcc-15-4016-gc534e37facc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Bug ID: 116901
Summary: pr110625_4.c fails on aarch64 since
r15-3794-g2c04f175de4f39
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116818
Bug ID: 116818
Summary: gcc.target/aarch64/sve/strided_load_5.c fails since
gcc-15-3735-g664e0ce580a8
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Bug ID: 115493
Summary: gcc.c-torture/execute/pr94734.c fails on MVE after
gcc-15-1054-g202a9c8fe7d
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Bug ID: 115248
Summary: aarch64/sve/pre_cond_share_1.c fails since
gcc-15-276-gbed6ec161be
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from Chris
1 - 100 of 451 matches
Mail list logo
