https://sourceware.org/bugzilla/show_bug.cgi?id=31924
Szabolcs Nagy changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #13 from Szabolcs Nagy ---
(In reply to Ard Biesheuvel from comment #12)
> RELR relocations fundamentally rely on the addend being present in the
> executable, as it is not stored anywhere else. This means
> --no-apply-dynamic-relo
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #9 from Szabolcs Nagy ---
it seems arm64 linux passes --no-apply-dynamic-relocs which means
the relative reloc addend is not stored to the referenced location
(0 is stored) and since -z pack-relative-relocs does not have the
addend
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #7 from Szabolcs Nagy ---
(In reply to H.J. Lu from comment #6)
> Does DT_RELR work in aarch64 glibc?
yes
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #4 from Szabolcs Nagy ---
i can confirm that boot fails depending on if vmlinux is linked with -z
pack-relative-relocs or not, so this is DT_RELR related.
i will try to debug this further.
--
You are receiving this mail because:
https://sourceware.org/bugzilla/show_bug.cgi?id=31847
Szabolcs Nagy changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=31850
Szabolcs Nagy changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
there should be no GOT entries allocated and no dynamic relocations in the
following binary:
$ cat bug.ld
OUTPUT_ARCH
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
relative relocation against an abs symbol is wrong, the GOT entry should be
initialized to the abs symbol value without dynamic relocation for it.
$ cat abs-got.s
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
$ cat bug.ld
OUTPUT_ARCH(aarch64)
SECTIONS
{
/DISCARD/ : { *(.discard) }
. = 0x1;
.text : { *(.text) }
. = 0x2
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
void foo(unsigned i, unsigned *p)
{
*p = i & 1;
}
with gcc -march=armv8-a+sve -O2 compiles to
foo:
fmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112987
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112987
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.42
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #27 from Szabolcs Nagy ---
for the record a minimal reproducer when a bti veneer branches to itself:
$ cat a.s
.global _start
.type _start, %function
_start:
b foo
.zero 0x0700
$ cat b.s
.zero 0x0100
.g
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #26 from Szabolcs Nagy ---
(In reply to Szabolcs Nagy from comment #25)
> - *_bti_veneer is global symbol (not local)
sorry this is wrong, the sym binding is local as expected.
--
You are receiving this mail because:
You are on
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #25 from Szabolcs Nagy ---
for the record i built a mame binary where
$ readelf -aW mame |grep
_ZN3emu6detail16device_registrar15register_deviceERNS0_21device_type_impl_baseE
885688: 084323c812 FUNCLOCAL DEFAULT
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
bti veneer is only needed if the target instruction is not bti (or
paciasp,...), but bfd ld sometimes emits the veneer unnecessarily. (gnu
property is for BTI marking)
(introduced by the fix
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
Szabolcs Nagy changed:
What|Removed |Added
Last reconfirmed||2023-10-05
Status|UNCONFI
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #20 from Szabolcs Nagy ---
(In reply to Szabolcs Nagy from comment #18)
> i tried the specified steps and the bug is not reproducible.
(In reply to Nick Clifton from comment #19)
> (In reply to Szabolcs Nagy from comment #18)
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #18 from Szabolcs Nagy ---
i tried the specified steps and the bug is not reproducible.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30867
--- Comment #2 from Szabolcs Nagy ---
on a second thought gold likely requires
AX_CXX_COMPILE_STDCXX(11, , mandatory)
in its configure.ac
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30867
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
--- Comment #1 from nsz at gcc dot gnu.org ---
see also bug 111479
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
maybe related to bug 111478
$ cat bug.c
float a, b, c;
void *d;
int e, f, g;
void p
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
$ cat bug.c
float a, d, e, f, g;
int b, c;
void h() {
for (; b; b++) {
for (; c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #12 from nsz at gcc dot gnu.org ---
(In reply to Jiangning Liu from comment #11)
> Hi Wilco,
>
> > "it means we will need a linker optimization to remove those redundant BTIs
> > (eg. by changing them into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=30076
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.41
Resolution|---
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
ld may insert stubs with indirect branch if the call target is out of reach for
the direct call/branch instruction.
In BTI enaled code two stubs should be inserted with
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
--- Comment #11 from Szabolcs Nagy ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Szabolcs Nagy from comment #9)
> > i ran into this again and i think the linker could relax 'adrp xN, weaksym'
> > into 'mov xN, 0' if weaksy
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
e.g. on aarch64 assembling
foo .req x0
.unreq foo ;
fails with
:2: Error: unknown register alias 'foo;'
the ; should be a line sep
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
--- Comment #8 from Szabolcs Nagy ---
still cannot reproduce it, the gcc i used for the build was
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/work/bgcc/install/libexec/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
--- Comment #6 from Szabolcs Nagy ---
sorry i don't know what is "a profiled lto build"
i tried using debian g++-12 in a container with new binutils
doing a normal build with same config as seen in the build log.
(did not apply the debian gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104689
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution
: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
the following code is miscompiled with gcc -O1
#define sysreg_read(regname
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
gcc emits DW_CFA_AARCH64_negate_ra_state (DW_CFA_window_save) for pac-ret
but it's valid to set the RA_SIGN_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
reduced from linux code on which gcc-12 warns now:
int foo(int x) {
switch(x) {
int y;
/* spuriously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768
--- Comment #3 from nsz at gcc dot gnu.org ---
well, protection mechanisms are rarely equivalent. neither scs nor
traditional stack protector are perfect.
to me compiler support for freestanding environments such as linux
makes sense. i cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i see this note/warning a lot during an aarch64 glibc build
since gcc-9, it seems to require -O -g, and seems
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
this is an optimization bug, i don't know which layer it should
be fixed so i report it as target bug.
cold path af
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
memory tagging intrinsics should be available when arm_acle.h
is included and __ARM_FEATURE_MEMORY_TAGGING is defined.
memory tagging is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618
--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Wilco from comment #3)
> I fixed this in GCC10:
> https://gcc.gnu.org/git/?p=gcc.git&a=commit;
> h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db
>
> So this just nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618
--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Florian Weimer from comment #1)
> Is the test case really valid? It involves an out-of-bounds array access,
> after all.
sorry you are right the indexes are too far, a better t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618
--- Comment #2 from nsz at gcc dot gnu.org ---
(In reply to Florian Weimer from comment #1)
> Is the test case really valid? It involves an out-of-bounds array access,
> after all.
no it doesn't, n is signed long and its value can b
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
gcc-8 and earlier can generate adrp with out of bounds offset
for hidden and local symbols.
i haven't yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98251
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
gcc-10 (and trunk) with -mbranch-protection=bti (or standard)
fails to generate bti c at function entry in some cases:
char *foo (const
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
consider:
int f(unsigned char **);
int g(char *p)
{
return f((unsigned char **)&p);
}
such code is almost surely w
https://sourceware.org/bugzilla/show_bug.cgi?id=26378
--- Comment #1 from Szabolcs Nagy ---
linux-kernel discussion:
https://lore.kernel.org/lkml/20200812160017.GA30302@linux-8ccs/
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
since binutils 2.35 i see WAX flags on some nobits sections:
$ cat a.s
.section.text.foo,"ax",@progbits
.global foo
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.36
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=26339
--- Comment #1 from Szabolcs Nagy ---
i will have to check the rest but at least 'mte' is not an architecture
extension in the gnu tools, there is 'memtag' instead
i.e. -march=armv8.5-a+memtag is valid but -march=armv8.5-a+mte is not.
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
--- Comment #7 from Szabolcs Nagy ---
patch https://sourceware.org/pipermail/binutils/2020-July/112643.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
--- Comment #6 from Szabolcs Nagy ---
note on 32bit arm, sh and or1k .plt sh_entsize == 4 which
has nothing to do whith the plt entry size (which can
vary on arm). on sparc the logic is more complicated and
the plt entry size is used in some c
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |11.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94791
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96001
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95920
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i'd expect this to be a tail call into the soft float add
operation on soft float targets:
fp_t foo(fp_t a, fp_t b)
{
return a + b;
}
e.g. on x86 with &#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Nick Desaulniers from comment #4)
> (In reply to nsz from comment #2)
> > ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> > the alloca problem is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
Bug 94515 depends on bug 94514, which changed state.
Bug 94514 Summary: aarch64: unwinding across mixed pac-ret and non-pac-ret
frames is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95129
--- Comment #1 from nsz at gcc dot gnu.org ---
i also opened bug 95128 to just configure the outline-atomics away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95128
--- Comment #2 from nsz at gcc dot gnu.org ---
i also opened bug 95129 to fix the runtime detection.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
the initializer in libgcc uses __getauxval which is not
available on non-gnu targets so outlining atomics is
ineffective.
change the runtime lse check in libgcc such
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
on aarch64, non-gnu targets likely want to turn outline atomics off
in their toolchain (since outlining is ineffective without the hwcap
based initializer that can select lse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
--- Comment #6 from nsz at gcc dot gnu.org ---
this is fixed for gcc 10.1, just not backported yet so i kept the bug open
https://sourceware.org/bugzilla/show_bug.cgi?id=25903
--- Comment #1 from Szabolcs Nagy ---
bug 14675 may be related
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: nsz at gcc dot gnu.org
CC: ian at airs dot com
Target Milestone: ---
$ cat a.c
#include
#include
#include
#include
static _Unwind_Reason_Code unwind_backtrace_callback
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
Neither __builtin_return_address nor __builtin_extract_return_address
strips the pointer authentication code (PAC) when compiling with
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
int foo(int x)
{
return x;
}
gcc -pg -mbranch-protection=pac-ret
gives
foo:
hint25 // paciasp
stp x29, x30, [sp, -32]!
mov x29, sp
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
__attribute__((target("branch-protection=bti")))
int foo(void)
{
label:
return 0;
}
compiles to
foo:
hint34 // bti c
hint36 // bti j
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
-mbranch-protection=pac-ret is not supported in ilp32
so i would expect the related attribu
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
function that may be indirectly called does not start with bti c:
void bar(int *);
void *addr;
int foo(int x)
{
label:
addr=&&label;
bar(&x);
return x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
--- Comment #1 from nsz at gcc dot gnu.org ---
i had a fix but it's not enough, so here is another test case:
__attribute__((noreturn)) void unwind(void);
int bar(void);
int global;
int foo(int x)
{
if (x==1) return 2;
int y = bar();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
nsz at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94646
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
pac-ret uses the .cfi_window_save directive to toggle between signed/unsigned
return address, alternatively .cfi_remember_state and .cfi_restore_state pair
can be used to keep
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
libgcc unwinder on aarch64 fails to keep track of pauth state and may try to
authenticate return addresses that were not signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
--- Comment #7 from nsz at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6)
> Can we close this issue now?
as far as *-musl* is concerned the bug is fixed,
but e.g. now android uses elf tls too, i'm not
sure what happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64, x86|aarch64
Status|NEW
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
x86 version of bug 92424
endbr64 is not right at the function label with
-fcf-protection=full -fpatchable-function-entry=1
void f
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
gcc may recompute the address used in a Q constraint
(which may be used for atomic load and stores).
static volatile int x[1];
int f()
{
int r;
asm volatile (&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91113
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64 |aarch64, x86
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822
--- Comment #3 from nsz at gcc dot gnu.org ---
it seems at least the following neon intrinsics are affected:
float32x2_t vmulx_laneq_f32 (float32x2_t, float32x4_t, const int);
float32x2_t vmul_laneq_f32 (float32x2_t, float32x4_t, const int
1 - 100 of 287 matches
Mail list logo
