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=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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #27 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #25)
>
> Indeed, it ICEs e.g. during CSE.
> Though, that also means it is just about luck, if something isn't a
> CONST_INT at expansion time but simplified into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #22 from Christophe Lyon ---
Sure, that's what I'm worried about.
So we can:
- leave this as-is for gcc-14 (known bug)
- commit what we discussed in #c15 #c16, (with an improved testcase as you
mentioned on the list,) thus at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #16 from Christophe Lyon ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050=edit
patch proposal
Here is the patch I propose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
> else if (VALID_MVE_PRED_MODE (mode))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #8 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #7 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > lowpart_subreg does not work either.
> >
> > If we put the predicates in a variable in the testcase, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #3 from Christophe Lyon ---
lowpart_subreg does not work either.
If we put the predicates in a variable in the testcase, then in
function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
116 [ _3 ]) 0) so taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #7 from Christophe Lyon ---
So yes indeed at r14-5423-gfbe4e64365ec7f, autoreconf will generate the same
contents, but starting at r14-5424-gdb50aea6259545 we get this discrepancy.
We can probably commit the "fixed" version, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #6 from Christophe Lyon ---
(In reply to Andrew Pinski from comment #1)
> The last time aclocal.m4 had an include for override.m4 was
> r9-3776-g22e052725189a4 .
IIUC that commit actually removed the include for override.m4 ?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Bug ID: 114748
Summary: libcpp aclocal.m4 and configure incorrectly
regenerated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #4 from Christophe Lyon ---
I'm wondering whether you missed check_effective_target_arm_arch_FUNC_link and
friends?
Maybe check_effective_target_arm_arch_v7a_neon_link would work here, but it
does not use the exact same flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #2 from Christophe Lyon ---
I think the last -march option overrides the previous one(s).
I'd say the test should use an effective-target which checks that linking is
actually OK rather than just a compile OK test. Not sure if an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Bug ID: 114522
Summary: [14 regression] gcc.target/arm/aes_xor_combine.c
scan-assembler-not veor fails after
r14-9692-g839bc42772ba7a
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
--- Comment #3 from Christophe Lyon ---
What I meant by arm-* is that we see the same issue on several of the
configurations we test, as can be seen on
https://linaro.atlassian.net/browse/GNU-1100
We have recently improved the extraction of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc64-linux-gnu arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
Bug ID: 113437
Summary: gcc.dg/tree-ssa/pr95906.c fails on arm since
g:6686e16fda4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Bug ID: 113425
Summary: gcc.dg/fold-copysign-1.c fails on arm since
g:7cbe41d35e6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278
Bug ID: 113278
Summary: analyzer tests relying on fileno() fail on arm-eabi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113276
Bug ID: 113276
Summary: gcc.dg/torture/fp-double-convert-float-1.c fails at
execution on arm cortex-m33
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113275
Bug ID: 113275
Summary: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c
fail after gcc-14-5396-ged52bc2e30c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #4 from Christophe Lyon ---
@mkretz, this commit may also be of interest for some more context:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #1 from Christophe Lyon ---
For gcc.target/arm/bfloat16_vector_typecheck* tests, the log says:
FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors)
Excess errors:
bfloat16_vector_typecheck_1.c:122:17: error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Bug ID: 112698
Summary: gcc-14-5617-gb8592186611 introduces regressions in
bfloat16_vector_typecheck_1.c for cortex-m0 and
cortex-m3
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #3 from Christophe Lyon ---
The original problem is fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628998.html, and it seems
better not to call GLIBCXX_CHECK_LINKER_FEATURES and silently hide a potential
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #2 from Christophe Lyon ---
Oops sorry I pushed an unwanted patch, which I reverted with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #12 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #11)
> Please file a separate bug for these failures.
Thanks for the pointers, I digged a bit more, and filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
Bug ID: 111238
Summary: libstdc++ tests should use -Wl,-gc-sections in more
configurations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Christophe Lyon from comment #8)
> > On arm-eabi targets (thus, using newlib), we've noticed new errors:
>
> New since when? These files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
Bug ID: 110986
Summary: aarch64 regressions after r14-3110-g7fb65f10285
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #8 from Christophe Lyon ---
Created attachment 55707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55707=edit
pr110378-1.C.083i.sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #20 from Christophe Lyon ---
Sorry for the typo in the date in the commit message :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #17 from Christophe Lyon ---
Thanks Andrew, I wasn't aware of vect_float_strict.
I confirm it makes the test UNSUPPORTED.
Can you commit the fix or do you want me to do it on your behalf?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #15 from Christophe Lyon ---
(In reply to Richard Biener from comment #14)
> (In reply to Christophe Lyon from comment #12)
> > The new testcase (gcc.dg/vect/pr110381.c) fails:
> > FAIL: gcc.dg/vect/pr110381.c -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
--- Comment #2 from Christophe Lyon ---
This regression appeared after the patch that re-implements vdupq, but the
issue is likely more generic.
velo r
I tried to update arm_init_mve_builtins() with:
+ if (in_lto_p)
+ {
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Bug ID: 110268
Summary: arm MVE intrinsics support broken with LTO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #3 from Christophe Lyon ---
So we have a different behavior in
libstdc++-v3/include/experimental/bits/simd_detail.h:
#if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__)
#define _GLIBCXX_SIMD_HAVE_NEON_A32 1
#else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #2 from Christophe Lyon ---
Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but
fails when forcing -march=armv8-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
Bug ID: 110050
Summary: experimental/simd/pr109822_cast_functions.cc fails on
arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #11 from Christophe Lyon ---
Thanks, trunk is now OK on both arm and aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #8 from Christophe Lyon ---
I guess gcc185 is an aarch64 machine? (as opposed to arm)
I confirm your patch fixes the problem on aarch64 (the testcase now passes),
but it still fails on arm, with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #6 from Christophe Lyon ---
> trunk or the backport? I tested trunk on gcc185. Will check.
That's on trunk (didn't check on the branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #5 from Christophe Lyon ---
Not sure how to update/fix the testcases though?
Since they get the declaration of fclose from stdio.h, we'd need to make
dg-error conditional to the glibc version in use, which seems unpractical.
Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Christophe Lyon from comment #0)
> > Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> > configure?
>
> We only do a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #5 from Christophe Lyon ---
Fixed on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #10 from Christophe Lyon ---
Can you try to revert my patches:
f0d3b6e384a68f8b58bc750f240a15cad92600cd
ccb9c7b129206209cfc315ab1a0432b5f517bdd9
and remove your patch at comment #5 ?
You should still see the problem you reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #6 from Christophe Lyon ---
(In reply to James McKelvey from comment #5)
> This works:
>
> $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
> 2c2
> < MULTILIB_DIRNAMES = 64
> ---
> > MULTILIB_DIRNAMES = 64 32
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #4 from Christophe Lyon ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #3 from Christophe Lyon ---
and patching test_dfp_17.c like so:
- ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */
+ ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */
makes it pass on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #2 from Christophe Lyon ---
Confirmed.
In test_dfp_17.c we have:
ARG(_Decimal64, 11.0dd, D0)
DOTS
ANON(struct z, a, D1)
ANON(struct z, b, STACK)
ANON(int , 5, W0)
ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
--- Comment #9 from Christophe Lyon ---
Indeed it works again on trunk, I bisected and it started with one of our
commits: r12-3958-g4c7731081647c22cbd249dc0faa20c3df9ed6411
Author: Richard Biener
Date: Wed Sep 29 11:18:23 2021 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107119
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #7 from Christophe Lyon ---
Indeed, but I am surprised it seems to compile for cortex-m4?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #5 from Christophe Lyon ---
Could you share the preprocessed source file in the M3 and M4 cases along with
the full command line used to compile it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #3 from Christophe Lyon ---
Interesting
Did you use the same target triplet?
arm*-*-uclinuxfdpiceabi is handled differently from
arm-buildroot-uclinux-uclibcgnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #17 from Christophe Lyon ---
I think Torbjorn is right, at the fix seems as simple as handling "-T" the same
as "-Xlinker" in gcc_adjust_linker_flags_list.
However, looking at the GCC documentation, under "Linker Options", I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
--- Comment #4 from Christophe Lyon ---
(In reply to Richard Weickelt from comment #3)
> @Christophe Lyon,
>
> my use-case is that vendor A provides a binary blob of a library to vendor
> B. Both A and B ensure that they use the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
Bug ID: 106177
Summary: LTO interoperability Linux/Windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669
Bug ID: 105669
Summary: DFP to HF (_Float16) conversions use incorrect
rounding
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Known to fail||8.5.0, 9.4.1
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Bug ID: 105549
Summary: aarch64: Wrong va_arg alignment handling
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #5 from Christophe Lyon ---
> Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since
> the test involves floats.
I was wrong and your proposal of arm_v8_1m_mve_ok looks fine (since actually
there is no ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #4 from Christophe Lyon ---
Other MVE tests are in gcc.target/arm/simd/ (eg mve-vcmp-f32.c), maybe it's
best to keep them in the same place?
Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since the
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2022-04-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312
--- Comment #5 from Christophe Lyon ---
Sorry for the breakage, my patch shouldn't have modified the behavior for Neon.
I just moved the vcond_mask expander from neon.md to vec-common.md.
With Neon, I think we should have both v4sfv4si and
1 - 100 of 351 matches
Mail list logo
