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 ?
>
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Running either 'autoreconf' or 'aclocal -I ../config' in libcpp/ generates
aclocal.m4 and configure scripts with slightly different contents
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
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
After g
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
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Also seen on arm targets.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
We have detected the following regression since gcc-14-7124-g6686e16fda4:
FAIL: gcc.dg
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: tamar.christina at arm dot com
Target Milestone: ---
Since g:7cbe41d35e6 (gcc-14-7115-g7cbe41d35e6), we have noticed the following
regression
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
A few analyzer tests relying on fileno() fail on arm-eabi:
c-c++-common/analyzer/fileno-1.c
c-c++-common/analyzer/flex-with-call
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637422.html
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit g:ed52bc2e30c (arm: testsuite: avoid hard-float ABI
incompatibility with -march) a few testcases
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:
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-eabi
Commit
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:
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
Target Milestone: ---
As a follow-up to bug #104167, I've looked in more detail after Jonathan's last
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
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit r14-3110-g7fb65f10285 (MATCH: [PR110937/PR100798] (a ? ~b : b)
should be optimized to b ^ -(a)), I have noticed regressions on aarch64:
Running
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)
+ {
+
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since I rewrote (a lot of) MVE intrinsics, use of LTO is broken:
$ cat ~/t.c
#include
int main(void)
{
return vaddvq(vdupq_n_s8 (1));
}
# no LTO, OK:
$ arm-none-eabi-gcc
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|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit g:668d43502f465d48adbc1fe2956b979f36657e5f, I've noticed that
experimental
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
||clyon at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-11-10
--- Comment #1 from Christophe Lyon ---
Sorry
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
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello,
As reported in https://bugs.linaro.org/show_bug.cgi?id=5859, when compiling C
code with gcc and -flto on a Linux host and linking
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Support for conversions between DFP and _Float16 have been introduced with
r13-687-g308a0af4f91324.
For simplicity it uses intermediate
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
|P2
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
Severity|major |normal
Target||aarch64
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. I reduced
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
|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
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 1114 matches
Mail list logo