https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #6 from
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 =
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=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=98182
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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=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=94743
Christophe Lyon changed:
What|Removed |Added
Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
While working on enabling auto-vectorization for MVE, I noticed a missed
optimization compared to Neon:
#include
uint16_t *dest;
void func()
{
int i;
for (i=0;i<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The recently introduced if-to-switch-* tests fail on arm:
gcc.dg/tree-ssa/if-to-switch-2.c scan-tree-dump iftoswitch "Condition chain
with 3 BBs transformed into a s
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=96075
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since commit g:fddc7f0080f1f056c4d145451608ebd3e807422a, I have noticed ICEs on
aarch64
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=97944
Christophe Lyon changed:
What|Removed |Added
Version|11.0|10.2.1
--- Comment #1 from Christophe
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
These new tests fails to link on arm:
29_atomics/atomic_float/wait_notify.cc (test for excess errors)
29_atomics/atomic_integral/wait_notify.cc (test for excess errors
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since this new test was introduced, it fails randomly on arm, aarch64 and other
targets (apparently powerpc, ia64, m68k according to gcc-testresults).
The logs say:
terminate
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:
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
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Looking at the code generated for gcc.target/arm/simd/mve-vsub_1.c:
#include
void test_vsub_i32 (int32_t * dest, int32_t * a, int32_t * b) {
int i;
for (i=0; i<4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The new test gcc.dg/ipa/modref-2.c fails on arm and other 32-bits targets:
FAIL: gcc.dg/ipa/modref-2.c scan-ipa-dump modref "Parm 1
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The intrinsics test bf16_vstN_lane_2.c fails on aarch64_be:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O0
scan-assembler-times st2\\t{v0.h - v1.h}\\[2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Several arm/simd tests fail on armeb (as opposed to arm):
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Some of the recently added zero-scratch-regs-* tests fail on arm.
For instance when configuring GCC
--target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since commit r11-4614 (g:e881774d0dda6d5127eb8f0642f6edc16dc0b1e7), I've
noticed:
FAIL: gcc.dg/vect/pr91293-3.c execution test
on arm and aarch64
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=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=97616
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-4428 (g:4a369d199bf2f34e037030b18d0da923e8a24997) I have noticed
regressions on arm:
FAIL: gcc.dg/vect/bb-slp
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.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3822 (g:7e7352b2ad089ea68d689f3b79d93e3ee26326f7), I have noticed
several aarch64/SVE regressions:
gcc.target/aarch64/sve/mask_load_slp_1.c
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=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=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
||aarch64 arm
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Seen on arm & aarch64 too
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
Christophe Lyon changed:
What|Removed |Added
Target||arm
Target Milestone|---
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
When compiling with
-mthumb -mcpu=cortex-m55
I get:
cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322
--- Comment #2 from Christophe Lyon ---
Thanks, this patch does fix both builds for me.
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Created attachment 49322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49322=edit
preprocessed strtof_l.i
Si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322
Christophe Lyon changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that
FAIL: gcc.target/aarch64/pr90838.c scan-assembler-times and\t 2
This appeared between r11-3681 (g:29c650cd899496c4f9bc069d03d0d7ecfb632176)
and r11-3685
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=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 #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 #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 #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
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=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)
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36, I have noticed
several regressions on arm
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=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=97146
--- Comment #1 from Christophe Lyon ---
On arm, there is also:
FAIL: gcc.dg/fixed-point/composite-type.c (test for excess errors)
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3303 (g:6450f07388f9fe575a489c9309c36012b17b88b0) several testcases
now fail on arm
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3258 g:c7f4be78cb61006492d16375aba5392f580cd633
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
This testcase causes a false positive 'may be used uninitialized' warning when
compiled with -O2 -Wall. It is derived from libiberty/pex-win32.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088
--- Comment #2 from Christophe Lyon ---
(In reply to jos...@codesourcery.com from comment #1)
> On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote:
>
> > This happens because the testcase does
> > #define x (
> > and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #1 from Christophe Lyon ---
I see random results from one run to another, so it's likely that something is
not initialized correctly.
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Between r11-3230 and r11-3249 (g:052204fac580b21c967e57e6285d99a9828b8fac and
g:ecde1b0a467127714872785b9935fe7c580778f0), I've noticed:
FAIL: gcc.dg/analyzer/malloc-vs
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
When configuring gcc with --disable-libstdcxx-pch, two libstdc++ fail on arm
(linux and newlib targets) and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97056
--- Comment #2 from Christophe Lyon ---
No, it was failing at that time.
It started passing between r11-3093 and r11-3103, and fails again since
r11-3148.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3148 (g:8d3767c30240c901a493d82d9d20f306b2f0152d), I've noticed that:
FAIL: gcc.target/aarch64/sve/cost_model_2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #22 from Christophe Lyon ---
Yes, that fixes the build for aarch64, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97041
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95421
--- Comment #4 from Christophe Lyon ---
(In reply to SRINATH PARVATHANENI from comment #3)
> I see following intrinsics for AArch64 already implemented.
> vst3q_lane_p8
> vst3q_lane_s8
> vst3q_lane_u8
>
Yes, they are missing in the arm
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Commit g47ddf4c7b1d4471cb9534f27844ab5e4279c2168 (PR96043) has caused many
regressions on aarch64, the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #14 from Christophe Lyon ---
I that's easier for you, there are similar ICEs while running the GCC testsuite
for aarch64-elf (newlib build works):
Executed from: gcc.c-torture/compile/compile.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #13 from Christophe Lyon ---
Created attachment 49206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49206=edit
glibc testcase for aarch64 ICE
The vfprintf-internal.i preprocessed source from glibc-2.29 creates an ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #11 from Christophe Lyon ---
Ha sorry I missed the beginning (interleaved in the log with other commands):
during RTL pass: sched_fusion
vfprintf-internal.c: In function '__vfprintf_internal':
vfprintf-internal.c:1702:1: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
|ASSIGNED
Last reconfirmed||2020-09-08
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
since r11-3025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94595
--- Comment #1 from Christophe Lyon ---
For thumb2-cond-cmp-4.c (if ( (i >= '+') ? (j <= '-') : 1) ) we generate:
* cortex-m0:
f:
cmp r0, #42
ble .L3
movsr3, #45
movsr2, #0
lsrsr0, r1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96769
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Applying the same process as in PR71233, I have noticed a few MVE intrinsics
are not implemented:
__arm_vcvtnq_u32_f32
__arm_vqdmlashq_m_n_s16
__arm_vqdmlashq_m_n_s32
__arm_vqdmlashq_m_n_s8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96769
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #27 from Christophe Lyon ---
Created attachment 49172
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49172=edit
a32/a64 intrinsics not supported by the aarch32/arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #26 from Christophe Lyon ---
Created attachment 49171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49171=edit
v7 intrinsics not supported by the aarch32/arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #25 from Christophe Lyon ---
Created attachment 49170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49170=edit
a64 intrinsics not supported by the aarch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #23 from Christophe Lyon ---
Created attachment 49168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49168=edit
v7 intrinsics not supported by the aarch64 target
Update 2020-09-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #24 from Christophe Lyon ---
Created attachment 49169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49169=edit
a32/a64 intrinsics not supported by the aarch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #22 from Christophe Lyon ---
Applying the recipe from comment #6, the current list of duplicates is:
New ones:
2 vcmla_laneq_f16
2 vcmla_rot180_laneq_f16
2 vcmla_rot270_laneq_f16
2 vcmla_rot90_laneq_f16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #21 from Christophe Lyon ---
Created attachment 49167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49167=edit
Full list of intrinsics documented for a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #20 from Christophe Lyon ---
Created attachment 49166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49166=edit
Full list of intrinsics documented for a32/a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #19 from Christophe Lyon ---
Created attachment 49165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49165=edit
Full list of intrinsics documented for v7/a32/a64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #18 from Christophe Lyon ---
The list at
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
has a new format (the list is split in 146 pages, I couldn't find how to get
the list on a single page). So I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #17 from Christophe Lyon ---
Created attachment 49162
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49162=edit
Full Neon intrinsics list as of 2020-09-01.
Full Neon intrinsics list as of 2020-09-01.
301 - 400 of 1123 matches
Mail list logo
