https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99498
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547
Bug ID: 99547
Summary: [11 regression] g++.dg/modules/xtreme-header-5_c.C
-std=c++2a ICE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547
--- Comment #1 from Christophe Lyon ---
I read too quickly, on aarch64 the failing test is xtreme-header-3_c.C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
Christophe Lyon changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #7 from Christophe Lyon ---
Created attachment 50412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412&action=edit
proposed testcase
Here is a proposal for a testcase derived from the initial description:
- added relevant dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #12 from Christophe Lyon ---
I have tests in progress too (with and without the fix), except that I have
typedef uint32x4_t i;
instead of
typedef uint32x2_t i;
and I replaced the (__builtin_neon_hi *) cast with (int16_t*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #14 from Christophe Lyon ---
I can confirm that the new test (as described in comment #12) works:
- alone it results in ICE in the relevant configurations (skipped otherwise)
- with the patch, it passes in the relevant configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #13 from Christophe Lyon ---
For arm yes, but according to gcc-testresults, it's failing on ia64 and s390
too, at least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99665
Bug ID: 99665
Summary: GCC can generate FPU instructions not supported by the
.fpu directive it emits
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #18 from Christophe Lyon ---
Not a big deal if you forget, that's a detail :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
--- Comment #4 from Christophe Lyon ---
Oops sorry, indeed it's likely that several of my other patches in this area
introduced the same problem. I did lots of 'make check' though, too bad iwmmxt
isn't covered well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
--- Comment #6 from Christophe Lyon ---
Looks good to me, thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99727
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99727
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
Bug ID: 99773
Summary: ARM v8.1-m MVE interaction with -mfloat-abi not clear
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #3 from Christophe Lyon ---
I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
#define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
&& (bitmap_bit_p (arm_active_target.isa, \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786
--- Comment #2 from Christophe Lyon ---
This fixes the ICE:
diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
index 48ee659..86563d9 100644
--- a/gcc/config/arm/vec-common.md
+++ b/gcc/config/arm/vec-common.md
@@ -103,7 +10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #5 from Christophe Lyon ---
Compiling with -march=armv8.1-m.main+mve -mfloat-abi=hard defines:
TARGET_SOFT_FLOAT 1
TARGET_HARD_FLOAT 0
TARGET_HARD_FLOAT_ABI 1
TARGET_VFP_SINGLE 1
so indeed what you propose does the trick.
(Sorry I p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786
Christophe Lyon changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Christoph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
Christophe Lyon changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99937
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547
--- Comment #3 from Christophe Lyon ---
Apparently not, the last occurrence was with r11-7662
(g:9844eeff5abd129fab5a4cbd004b814c073a95a1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97726
--- Comment #3 from Christophe Lyon ---
Almost, but I still see vstn_lane_bf16_1.c failures in check-function-bodies on
armeb.
vdot-2-[12].c still fail, but I see failures on little-endian configs too, so
probably a different issue (I didn't che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
Bug ID: 100049
Summary: loop counter double increment with longjmp inside
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
--- Comment #3 from Christophe Lyon ---
Thanks for the prompt answers!
I did notice that putting the code into a single source file made behave "as
expected". I did check the longjmp docs but unfortunately missed the section
describing this cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
--- Comment #4 from Christophe Lyon ---
Actually 'man longjmp' says:
The compiler may optimize variables into registers, and longjmp() may
restore the values of other registers in addition to the stack pointer
and progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
--- Comment #7 from Christophe Lyon ---
I'm told that -fno-sched-interblock helps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067
--- Comment #5 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > Unfortunately this is causing many regressions in the GCC testsuite.
>
> Sigh! I'm not entirely surprise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
Bug ID: 100179
Summary: [12 regression] xtreme-header-2_a.H fails on arm-eabi
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
--- Comment #1 from Christophe Lyon ---
Similar errors noticed in libstdc++ testsuite:
17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
17_intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180
Bug ID: 100180
Summary: experimental/net/internet/address/v6/members.cc fails
on arm-eabi
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180
--- Comment #2 from Christophe Lyon ---
On trunk, the error message is:
FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98143
--- Comment #1 from Christophe Lyon ---
Current trunk generates for MVE:
ldr r3, .L3+16 @ 5 [c=12 l=4] *thumb2_movsi_vfp/5
vldr.64 d6, .L3 @ 7 [c=8 l=4] *mve_movv8hi/8
vldr.64 d7, .L3+8
ldr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
--- Comment #6 from Christophe Lyon ---
Yes, I confirm it's now fixed, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #3 from Christophe Lyon ---
Well, why does the warning remove the extensions? (+) It seems to indicate
they are not taken into account, which is confusing: it doesn't really say why
there is a conflict.
Why do you think -mcpu=cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97426
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
--- Comment #4 from Christophe Lyon ---
Yes I still see
FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378)
for
arm-none-linux-gnueabihf --with-cpu=cortex-a5
arm-none-eabi -mcpu=cortex-m[034]
but for instance arm-none-linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96376
--- Comment #3 from Christophe Lyon ---
I mentioned the configuration flags above:
--target armeb-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9
--with-fpu neon-fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Bug ID: 97513
Summary: [11 regression] aarch64 SVE regressions since r11-3822
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #2 from Christophe Lyon ---
Right, but the builds were broken before that (did not work with gcc-4.8.5 on
the host), so I didn't notice this problem ealier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616
Bug ID: 97616
Summary: [11 regression] bb-slp-58.c and bb-slp-59.c fail on
arm after r11-4428
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616
--- Comment #1 from Christophe Lyon ---
Actually these are not regressions, but new failures since the tests were just
added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691
Bug ID: 97691
Summary: [11 regression] pr91293-3.c fails since r11-4614
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699
Bug ID: 97699
Summary: [11 regression] zero-scratch-regs tests fail on arm
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97726
Bug ID: 97726
Summary: simd intrinsics tests fail on armeb
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97727
Bug ID: 97727
Summary: bf16_vstN_lane_2 test fails on aarch64_be
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766
Bug ID: 97766
Summary: ipa/modref-2.c fails on 32 bits targets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Bug ID: 97875
Summary: suboptimal loop vectorization
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #2 from Christophe Lyon ---
Checking the Arm v8-M manual, my understanding is that this architecture does
not support unaligned vector loads/stores.
However, my understanding is that vldrw.32 accepts to load from addresses
aligned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #4 from Christophe Lyon ---
Not quite: as of r11-5140, I see:
FAIL: gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944
Bug ID: 97944
Summary: 30_threads/jthread/95989.cc fails randomly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948
Bug ID: 97948
Summary: C++2a synchronization tests fail to link on arm
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944
Christophe Lyon changed:
What|Removed |Added
Version|11.0|10.2.1
--- Comment #1 from Christophe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944
--- Comment #3 from Christophe Lyon ---
My testing is with cross-compilers, binutils-2.34, glibc-2.29, host is RHEL7
x86_64.
Note that Toon reported a failure on x86_64:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-November/630321.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98015
Bug ID: 98015
Summary: [11 regression] ICE in gimple_expand_vec_cond_expr
since g:fddc7f0080f1f056c4d145451608ebd3e807422a
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
--- Comment #15 from Christophe Lyon ---
Yes, the test fails on gcc-10 too.
I tried adding xfail vect_load_lanes in gcc-9, and it correctly makes the test
XFAIL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
Bug ID: 98123
Summary: if-to-switch tests fail on arm
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98143
Bug ID: 98143
Summary: arm: missed vectorization with MVE compared to Neon
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
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=95056
--- Comment #4 from Christophe Lyon ---
Yes, it started passing again with r11-4728
g:4d76079fdfa3d36ebd95ac8b489519945e8ee88f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198
--- Comment #2 from Christophe Lyon ---
Can you check with gcc trunk?
There were recent fixes in the handling of noinit/persistent attribute:
g:762ca20364a590be2cb9c79c0101ccbff74b5de1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198
--- Comment #4 from Christophe Lyon ---
This simple patch avoids the ICE:
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 1d2ab7c..8847932 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -767,6 +767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
--- Comment #8 from Christophe Lyon ---
Indeed if-to-switch-1.c fails on aarch64 too, the other ones pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #4 from Christophe Lyon ---
In both cases (Neon and MVE), DR_TARGET_ALIGNMENT is 8, so the decision to emit
a useless loop tail comes from elsewhere.
And yes, MVE vldrw.32 and vstrw.32 share the same alignment properties.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #5 from Christophe Lyon ---
Interestingly, if I make arm_builtin_support_vector_misalignment() behave the
same for MVE and Neon, the generated code (with __restrict__) becomes:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #6 from Christoph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767
--- Comment #1 from Christophe Lyon ---
Patch sent for review:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554956.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
--- Comment #1 from Christophe Lyon ---
Patch sent for review:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554957.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228
Bug ID: 97228
Summary: [11 regression] New ICEs on arm since r11-3426
g:10843f8303509fcba880c6c05c08e4b4ccd24f36
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228
--- Comment #1 from Christophe Lyon ---
It causes regressions in fortran too:
gfortran.dg/assumed_rank_bounds_3.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (internal compiler error)
gfortran.dg/assumed_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94595
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
--- Comment #1 from Christophe Lyon ---
The following intrinsics are implemented, but not documented:
__arm_vqrdmlashq_n_u8
__arm_vqrdmlahq_n_u8
__arm_vqdmlahq_n_u8
__arm_vqrdmlashq_n_u16
__arm_vqrdmlahq_n_u16
__arm_vqdmlahq_n_u16
__arm_vqrdmlash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
--- Comment #2 from Christophe Lyon ---
Patch for __arm_vcvtnq_u32_f32 sent:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555485.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
--- Comment #3 from Christophe Lyon ---
Patch for vqdmlash* sent:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555497.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
--- Comment #4 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #1)
> The following intrinsics are implemented, but not documented:
> __arm_vqrdmlashq_n_u8
> __arm_vqrdmlahq_n_u8
> __arm_vqdmlahq_n_u8
> __arm_vqrdmlashq_n_u16
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
--- Comment #6 from Christophe Lyon ---
Thanks for the confirmation, I've just sent a patch to remove them:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/71.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97312
Bug ID: 97312
Summary: [11 regression] aarch64/pr90838.c fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322
Christophe Lyon changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322
Bug ID: 97322
Summary: [11 regression] ICE in int_mode_for_mode, at
stor-layout.c:404 on arm
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322
--- Comment #2 from Christophe Lyon ---
Thanks, this patch does fix both builds for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
Bug ID: 97327
Summary: -mcpu=cortex-m55 warns without -mfloat-abi=hard or
-march=armv8.1-m.main
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
Christophe Lyon changed:
What|Removed |Added
Target||arm
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #1 from Christophe Lyon ---
Similarly:
-mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp
cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main'
switch
-mcpu=cortex-m55+nomve -march=armv8.1-m.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 437 matches
Mail list logo
