gm2
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]