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
: 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
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
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=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();
: 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;
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.0
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
: 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
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
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
: 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
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
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.
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=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=94514
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=94697
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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=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
-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=95920
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
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=94791
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=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 #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" constrai
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
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=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&root=gcc&view=rev
Log:
microblaze: fix PR65649
microblaze-linux-musl build fails
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=91737
nsz at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #6 from nsz at
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&root=gcc&view=rev
Log:
musl: Fix invalid tls model in libgomp and libitm PR919
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=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=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=91113
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: ---
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
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
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
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=88954
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=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=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=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=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 tar
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 at
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.
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
some code does not include c++ headers in the top level but has
extern "C" {
#include
}
this is invalid c++ (simila
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85729
--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #3)
> Does that fix it?
yes, thanks.
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
: 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 co
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
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
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"(
: 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__
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
: 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 is
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 su
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.
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=91970
--- Comment #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.
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 -fround
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 #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 #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=83105
--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> Any reason why this should be a supportable configuration? I want hard
> float, but don't care what CPU/FPU I target...
i think there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
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=83834
--- Comment #8 from nsz at gcc dot gnu.org ---
ok it's because of 'void f()' vs 'f()'
old:
8133 cxx_sym = bfd_demangle (link_info.output_bfd, sym,
Value returned is $2 = 0x2695a00 "void std::call_onc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
--- Comment #12 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #10)
> This should fix it:
>
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -58,9 +58,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83845
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
on aarch64_be-none-elf i see
FAIL: gcc.target/aarch64/sve/extract_1.c -march
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14557
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
noticed on aarch64 recently that
gcc -c -O3 -g gcc/gcc/testsuite/gcc.c-torture/compile/limits-blockid.c
is much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84040
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva 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=90478
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=90539
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
nextafterf(FLT_MIN,0), nextafter(DBL_MIN,0), nextafterl(LDBL_MIN,0) should
signal the underflow exception (c99 annex F requirement), but now gcc constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86420
--- Comment #5 from nsz at gcc dot gnu.org ---
this fixed the glibc test failures for me.
(-ftrapping-math does not affect the const folding of arithmetics, i guess for
library functions it does, it would be less confusing if that was consistent)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625
--- Comment #19 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Aug 17 17:26:11 2018
New Revision: 263624
URL: https://gcc.gnu.org/viewcvs?rev=263624&root=gcc&view=rev
Log:
Fix poly types after PR tree-optimization/7162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
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=86771
--- Comment #11 from nsz at gcc dot gnu.org ---
Created attachment 44562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44562&action=edit
bad rtl dump of combine pass
attached good and bad dump of combine, i also tried to look at th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #12 from nsz at gcc dot gnu.org ---
the wrong string seems to be caused by a missing ldm
good main:
...
mov r4, #0
str r4, [sp, #32]
mov r2, #2
str r2, [sp, #36]
add
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i think the following inconsistency is problematic:
on a hard float toolchain (-mfloat-abi=hard):
$ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv7-a a.c ; echo $?
cc1: error
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i think it's since r257631 that assembler time went from 1s to 50s on
aarch64-linux-gnu, this seems a bit excessiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83915
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #3)
> I can't reproduce on gcc116.fsffrance.org. The assembler completes in less
> than a second for both -gno-inline-points and without.
>
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i see
FAIL: g++.dg/template/overload15.C -std=c++98 (test for excess errors)
FAIL: g++.dg/template/overload15.C -std=c++11 (test for excess errors)
FAIL: g++.dg/template/overload15.C -std=c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84465
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79064
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i expected f1 and f2 to compile to the same code:
unsigned g;
void f1(unsigned count) {
unsigned i;
for (i = 0; i < count ; i++) g++;
}
void f2(unsigned co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
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=14557
--- Comment #23 from nsz at gcc dot gnu.org ---
(In reply to felix from comment #21)
> > va_list ap2;
> > va_copy(ap2, ap);
>
> > and then use &ap2, this always works.
>
> > the proposed macros are both broke
1 - 100 of 242 matches
Mail list logo
