: 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://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
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://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_STATE
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 affects
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
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=commit;
> h=7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db
>
> So this just needs t
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 bette
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 val
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 found
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 **));
}
such code is almost surely wrong
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 'typedef
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
: 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
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
: 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
: 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=&
bar();
return x;
}
with -O2 -mbr
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 happ
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822
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=91938
--- Comment #5 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Dec 3 11:13:38 2019
New Revision: 278932
URL: https://gcc.gnu.org/viewcvs?rev=278932=gcc=rev
Log:
musl: Fix invalid tls model in libgomp and libitm PR91938
Musl does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #6 from nsz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #7 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Nov 15 17:39:14 2019
New Revision: 278308
URL: https://gcc.gnu.org/viewcvs?rev=278308=gcc=rev
Log:
microblaze: fix PR65649
microblaze-linux-musl build fails without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #31 from nsz at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #28)
> [ "ws" needs at least a Power7, btw. ]
powerpc64le-* implies power8 and that's where this came up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #30 from nsz at gcc dot gnu.org ---
i think it is not the end of the world if the asm constraint api
changes in this case: fixing musl is easy because it's not super
important to optimize fmin, fminf, fmax, fmaxf in libc (if it were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #6 from nsz at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #5)
> -- LLVM should support "wa", since that is *the* constraint for VSX
> registers.
> -- musl should use the "wa"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #2 from nsz at gcc dot gnu.org ---
note that "ws" is now supported by clang, but "wa" is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #1 from nsz at gcc dot gnu.org ---
seems to be broken since r271916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #9 from nsz at gcc dot gnu.org ---
ok i was looking at the wrong code, didn't know libgcc2,
i agree that's the right way to fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #7 from nsz at gcc dot gnu.org ---
i think the code snippet i posted is more efficient and significantly
smaller than using libgcc (which also sounds hard to wire up to do the
right thing). the code sequence can possibly be even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #5 from nsz at gcc dot gnu.org ---
ok so the real problem is that libgcc does not define
FP_INIT_ROUNDMODE and FP_HANDLE_EXCEPTIONS etc for
hardfloat arm targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
> Don't you need #pragma STDC FENV_ACCESS?
yes, for iso c conformance you need it, but gcc does not
handle it anyway, instead it requires -frounding-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
on arm-* with
#include
#include
int main()
{
long long x = (1LL << 60) - 1;
double y;
fesetround(FE_DO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
--- Comment #3 from nsz at gcc dot gnu.org ---
i opened a glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=25051
but i think this bug should be kept open for non *-linux*-gnu* targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
--- Comment #2 from nsz at gcc dot gnu.org ---
if you really want this optimization then libgomp has to do checks
to guarantee that the target libc supports this usage and only
enable it when it's 100% safe. (e.g. musl or bionic does not support
: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
initial-exec tls is only valid in a dso if there is a guarantee
that the dso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
mips64 syscall code in musl is like
#define __NR_getpid 5038
static inline long __syscall0(long n)
{
register long r7 __asm__("$7");
register long r2 __asm__
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
this used to work for me:
double fmax(double x, double y)
{
__asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
may be a -Wformat bug only, but the c++ front-end seems
to use the wrong type:
#include
struct X {
unsigned long long a: 1;
} x;
void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i'd expect a*b+c to generate the same code as __builtin_fmaf(a,b,c)
when hw instruction is available for fmaf, but the later generates
significantly worst code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
to declare vector functions on aarch64 for one simd architecture only,
support for the openmp 5.0 declare variant syntax is required, but
full support for the omp declare variant pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
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=90478
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
consider
typedef __Float32x4_t vec;
__attribute__((aarch64_vector_pcs))
vec f(vec a0, vec a1, vec a2, vec a3, vec a4, vec a5, vec a6, vec a7)
{
vec t0, t1, t2, t3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #18 from nsz at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #16)
> I've noticed this problem on arm and aarch64 native builds too.
> But my cross-compilers (using QEMU as simulator) still pass this test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|nsz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #14 from nsz at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to nsz from comment #12)
> > i don't know how to change this to false for IEEE_SUPPORT_HALTING
> > on aarch64 and arm targets,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #12 from nsz at gcc dot gnu.org ---
this got reverted because of bug 88678
and because compile time and runtime support_halting are different.
the compile time value is unconditionally true, which is wrong for
aarch64 and arm:
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
--- Comment #21 from nsz at gcc dot gnu.org ---
this fix undid the change for bug 78314
do you plan to backport it to gcc 7,8 branches ?
note that in principle on targets where trapping is not supported
the "immediate alternate exce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
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=88954
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
1 - 100 of 242 matches
Mail list logo
