[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gm2 running endlessly
From: |
Gaius Mulley |
Subject: |
Re: gm2 running endlessly |
Date: |
Thu, 04 Jan 2024 01:58:40 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Rudolf Schubert <rudolf@muc.de> writes:
> Hi Gaius,
>
> I'm still seeing gm2 going into an endless loop with my 'big' squash1.mod.
> As additional information, when running 'top' I can see that 'cc1gm2' is
> grabbing more and more memory. Perhaps in a free minute you might have a
> look at it;-)
>
>
> BR
>
> Rudolf
Hi Rudolf and John,
I've a bugfix for the infinite compilation:
$ gm2 --version
gm2 (GCC) 14.0.0 20231215 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ time ./mach_squash1
cc -c unix.c
gm2 -fiso -c Ctv2.mod
gm2 -fiso -fsoft-check-all squash1.mod Ctv2.o unix.o -o squash1 -lc -lcrypt -lm
^C
real 0m39.368s
user 0m0.072s
sys 0m0.006s
On John's code it compiles in 3m 50 secs:
$ time gm2 -g -c Blowup.mod
real 3m50.879s
user 3m49.539s
sys 0m1.323s
# On a development branch (dated 20231101) I get better results:
$ gm2 --version
gm2 (GCC) 14.0.0 20231101 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ time ./mach_squash1
cc -c unix.c
gm2 -fiso -c Ctv2.mod
gm2 -fiso -fsoft-check-all squash1.mod Ctv2.o unix.o -o squash1 -lc -lcrypt -lm
real 0m11.259s
user 0m11.090s
sys 0m0.168s
I need to port the bug fix from a developer copy of gcc to the master
branch and retest before pushing, but it appears to work on this
branch.
On John's code it compiles in 44 secs:
$ time gm2 -g -c Blowup.mod
real 0m44.424s
user 0m43.213s
sys 0m1.207s
There must be bug remaining relating to the resolving of constant arrays
(44 secs is still way too long for a small program - but at least it is 5x
faster than before :-). It also eats up memory - so I'll continue to
hunt this down
regards,
Gaius