https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122010
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120169
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
--- Comment #17 from Mikael Pettersson ---
(In reply to John Paul Adrian Glaubitz from comment #16)
> Once is enough, just to see whether the ICE I reported above is still there.
The fortran ICE during bootstrap is still there as of gcc-16-2025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120165
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121852
--- Comment #4 from Mikael Pettersson ---
With -O2 -fno-gcse -ftree-slp-vectorize it started at r11-6188-g0b76990a9d75d9:
0b76990a9d75d97b84014e37519086b81824c307 is the first new commit
commit 0b76990a9d75d97b84014e37519086b81824c307
Author: R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121852
--- Comment #3 from Mikael Pettersson ---
Plain -O3 works, but with -O2 -fno-gcse -ftree-slp-vectorize 11.5.0 reproduces
the wrong-code while 10.5.0 does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121852
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
--- Comment #15 from Mikael Pettersson ---
(In reply to John Paul Adrian Glaubitz from comment #13)
> (In reply to Mikael Pettersson from comment #12)
> > gcc-16-20250727 bootstraps fine for me with a local patch to enable LRA, and
> > --enable-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121747
--- Comment #4 from Mikael Pettersson ---
Bus error on a SPARC usually means "alignment error".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121557
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121577
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121730
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121704
--- Comment #6 from Mikael Pettersson ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Created attachment 62223 [details]
> > Slightly modified version
>
> this slightly modified version adds alw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121558
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121704
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121675
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121465
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121661
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120516
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120560
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121347
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121648
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118358
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118358
--- Comment #4 from Mikael Pettersson ---
(In reply to Tamar Christina from comment #1)
> Is the target backend gcc/config/xtensa/xtensa.md? there are patterns LRA is
> using that I can't find.
In case you haven't already spotted it, the backen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121535
--- Comment #5 from Mikael Pettersson ---
ia64 could implement TARGET_ZERO_CALL_USED_REGS itself instead of falling back
on the generic implementation. That would let it handle quirks like this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121336
--- Comment #1 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/691317.html
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to build a cross to cris-elf with the recently released
binutils-2.45 fails:
> cris-unknown-elf-as --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121260
--- Comment #4 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690836.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121260
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120998
--- Comment #2 from Mikael Pettersson ---
(In reply to James K. Lowden from comment #1)
> > 20250615 (last good snapshot) and 20250622 (first bad snapshot) I can no
> > longer bootstrap
>
> Please indicate if this problem remains with snapshot
: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Since sometime between 20250615 (last good snapshot) and 20250622 (first bad
snapshot) I can no longer bootstrap gcc-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120070
--- Comment #5 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #4)
> Bisected between 14.2.0 (old/good) and 15.1.0 (new/bad).
>
> 9cebf1234b88e55a04071bd55c9ec4e22c0899e6 is the first new commit
> commit 9cebf1234b88e55a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120070
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
--- Comment #4 from Mikael Pettersson ---
Maybe it's moot given Jakub's observation, but git bisect identified
9d20529d94b23275885f380d155fe8671ab5353a is the first new commit
commit 9d20529d94b23275885f380d155fe8671ab5353a (HEAD)
Author: Richa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
--- Comment #2 from Mikael Pettersson ---
It's enough to compile with: -std=gnu89 -Os -fno-omit-frame-pointer.
Using -O2 or dropping -fno-omit-frame-pointer hides the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118485
--- Comment #9 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #5)
> I see the same failure with vanilla gcc-15-20250119 in a native bootstrap on
> m68k-linux-gnu.
>
> Trying a bisect, but it'll be painfully slow.
gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #3 from Mikael Pettersson ---
Is that before or after you built the target glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #1 from Mikael Pettersson ---
How did you configure this gcc?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Created attachment 60451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60451&
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Created attachment 60426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60426&action=edit
/proc/cpuinfo from
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to bootstrap gcc-15-20250202 on aarch64-linux-gnu fails with:
/mnt/scratch/objdir15/./prev-gcc/xg++ -B/mnt/scratch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118485
--- Comment #6 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #5)
> I see the same failure with vanilla gcc-15-20250119 in a native bootstrap on
> m68k-linux-gnu.
gcc-15-20250119 bootstraps fine with Ada enabled on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118485
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #2 from Mikael Pettersson ---
(In reply to Sam James from comment #1)
> You're saying 12..14 all failed too, or you didn't try those?
I suspect it's related to gcc-11 being the last release where D could be
bootstrapped with only a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #8 from Mikael Pettersson ---
According to glibc's sysdeps/microblaze/atomic-machine.h, microblaze cannot do
atomic operations on bytes or shorts, but __atomic_test_and_set is defined to
operate on a single byte, which would make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #4 from Mikael Pettersson ---
Note that a microblaze-unknown-linux-gnu toolchain builds just fine with
gcc-14, glibc, and c++ enabled, so perhaps it's a _bit_ premature to deprecate
it just because of these failures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488
--- Comment #13 from Mikael Pettersson ---
And gcc.dg/torture/pr116915.c which was also added for this BZ invokes UB on
int16 targets:
pr116915.c: In function 'main':
pr116915.c:8:20: warning: iteration 32768 invokes undefined behavior
[-Waggre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117186
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
Mikael Pettersson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
--- Comment #2 from Mikael Pettersson ---
(In reply to Andrew Pinski from comment #1)
> ```
> #define B ((int) ((unsigned char) '\234' * (unsigned)scale + (unsigned char)
> 'b'))
> ```
That fixes the test case on the five 16-bit targets.
I'll
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The following is adapted from gcc.dg/cpp/charconst-3.c:
==snip==
void foo (int);
void __attribute__ ((__noreturn__)) _exit (int);
#define A '\234b'
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The pr52286.c test case does the following on 16-bit targets:
long a, b;
asm ("" : "=r" (a) : &qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #6 from Mikael Pettersson ---
Probably fixed for gcc-14.1.0 by e0c1476d5d7c450b1b16a40364cea4e91237ea93. The
original proposed patch no longer applies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #14 from Mikael Pettersson ---
Since gcc-15 wouldn't build due to an unrelated issue, I applied the fmo patch
to gcc-14.1 (which also has this bug) and bootstrapped that. Alas it didn't
make any difference, same error in stage2 as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #13 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #9)
> (In reply to Manolis Tsamis from comment #8)
> > Created attachment 58335 [details]
> > Do not modify live_out registers
> >
> > After looking again at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #9 from Mikael Pettersson ---
(In reply to Manolis Tsamis from comment #8)
> Created attachment 58335 [details]
> Do not modify live_out registers
>
> After looking again at the dumps from PR112415, which I believe is closely
> rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
--- Comment #5 from Mikael Pettersson ---
I ran a git bisect between 11.4.0 and 12.3.0, which identified the following as
fixing this test case:
2e96b5f14e4025691b57d2301d71aa6092ed44bc is the first new commit
commit 2e96b5f14e4025691b57d2301d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #8 from Mikael Pettersson ---
According to my git bisect, the assembler error started with
551935d11817dd5b139d66c36f62c0f0eba0db06 is the first new commit
commit 551935d11817dd5b139d66c36f62c0f0eba0db06
Author: Alexandre Oliva
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #5 from Mikael Pettersson ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #4 from Mikael Pettersson ---
I'm not sure this is an m68k bug. I tried several targets that have
auto-increment addressing modes (m68k, pdp11, msp430, vax, aarch64) and none of
them would use auto-increment for this test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #4 from Mikael Pettersson ---
Confirmed:
04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a is the first new commit
commit 04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a
Author: Manolis Tsamis
Date: Mon Oct 16 13:08:12 2023 -0600
Implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #3 from Mikael Pettersson ---
git bisect identified the following as the start of this error:
# new: [04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a] Implement new RTL
optimizations pass: fold-mem-offsets
Note the error still reproduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #6 from Mikael Pettersson ---
Updated patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #12 from Mikael Pettersson ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643276.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #7 from Mikael Pettersson ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643383.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #2 from Mikael Pettersson ---
/mnt/scratch/gcc-14-20240107/configure --prefix=/mnt/scratch/install14
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disab
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
gcc-14 native(*) bootstrap on m68k-linux-gnu fails during stage2 as follows:
ranlib libgcov.a
/mnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
--- Comment #2 from Mikael Pettersson ---
I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting
vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
Mikael Pettersson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #11 from Mikael Pettersson ---
Reduced test case:
> cat ../pr110934.c
extern double clobber_fp0(void);
void f(void) { clobber_fp0(); }
> gcc/xgcc -Bgcc -fzero-call-used-regs=used -fPIC -O -S ../pr110934.c
during RTL pass: zero_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #5 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641800.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #4 from Mikael Pettersson ---
Created attachment 56985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56985&action=edit
proposed fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110627
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109133
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #6 from Mikael Pettersson ---
Created attachment 56965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965&action=edit
Preliminary patch, only tested on the test case so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #9 from Mikael Pettersson ---
Created attachment 56961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56961&action=edit
proposed fix, only tested on the given test case so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #8 from Mikael Pettersson ---
The generic code synthesizes a move from CONST0_RTX (XFmode) to an XFmode FP
reg, and that causes the ice. Forcing the mode of both to SFmode or DFmode
avoids the ice and generates sane-looking code. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #7 from Mikael Pettersson ---
The issue appears to be the clearing of FP regs. If I add an m68k-specific
version of TARGET_ZERO_CALL_USED_REGS which handles integer (address and data)
regs but skips FP regs, then the test case compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #6 from Mikael Pettersson ---
Affects gcc-11 and newer, gcc-10 and older are ok. Started with:
d10f3e900b0377b4760a090b0f90371bcef01686 is the first new commit
commit d10f3e900b0377b4760a090b0f90371bcef01686
Author: qing zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #2 from Mikael Pettersson ---
Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
disabling similar loop-to-call transformations people have been objecting to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #7 from Mikael Pettersson ---
Patch posted after bootstrap and regression testing on m68k-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640177.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
--- Comment #2 from Mikael Pettersson ---
It appears the test case comes from https://github.com/dxx-rebirth/dxx-rebirth/
(a port of the old Descent game engine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
--- Comment #8 from Mikael Pettersson ---
Can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #2 from Mikael Pettersson ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #5 from Mikael Pettersson ---
To get guaranteed tail-calls to work you need to adjust the calling convention
for the caller as well as the callee. Things are trivial as long as parameters
always fit in registers. With parameters on th
1 - 100 of 474 matches
Mail list logo
