Dear maintainer:

I think this is an anomaly big enough to be reported.

During a rebuild of all packages in bookworm, I noticed that this package
takes 132 hours to build (in my autobuilders), while previously it took
only one hour and a quarter.

What could be the reason? Most of the time, it's executing tests:

Running /<<PKGBUILDDIR>>/src/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ...
WARNING: program timed out.
FAIL: gcc.c-torture/execute/builtins/abs-1.c execution,  -O1
WARNING: program timed out.
FAIL: gcc.c-torture/execute/builtins/abs-1.c execution,  -O2
WARNING: program timed out.
FAIL: gcc.c-torture/execute/builtins/abs-1.c execution,  -O3 -g
WARNING: program timed out.
FAIL: gcc.c-torture/execute/builtins/abs-1.c execution,  -Os
WARNING: program timed out.
FAIL: gcc.c-torture/execute/builtins/abs-1.c execution,  -Og -g
WARNING: program timed out.

Are those "timed out" messages normal/expected?

Thanks.

Yes, and my apologies for not getting back to the email you previously
sent me; you're right to report it here to get more eyeballs.
I'm not sure, I'm not able to reproduce. I do have an idea to cut down
on the build times in general, but I'm not sure it will help us.

I'm afraid almost anything is expected when it comes to the GCC test
suite. The 100x slowdown you're seeing is not expected; it's still
expected that running the test suite not take "too much" time.

Then again, I wonder if these timeouts reflect legitimate issues in the
package? If you compile, say, abs-1.c by hand using an installed gcc-sh-
elf assuming that's possible, and then try running it under sh-elf-run,
does it appear to timeout? That might not be normal, and closer
inspection of the source code would in that case be required to find if
this is a bug in the test program or in gcc/the simulator.

In summary, let's not paper over this issue just yet; there might
actually be something wrong here the test suite is catching.

El 1/2/23 a las 14:39, John Scott escribió:

I don't know, because I found about this by doing an archive-wide rebuild
of all packages in bookworm (I didn't even go as far as actually
using the package).

My theory is that this is due to some behaviour change in
gcc-12-source, the most important build-dependency, but
I would still hope that such change could be disabled in
the gcc-sh-elf package itself in some way.

I've put all my build logs here for you to see:

https://people.debian.org/~sanvila/build-logs/gcc-sh-elf/

If you do

tail -n1 *

on them you will see that this was taking between one and two hours
until 2022-07.

Then something happened between 2022-07 and 2022-12 which
made the build time to increase so much.

The last three builds deserve an explanation:

==> gcc-sh-elf_4_amd64-20221211T112134.352Z <==
Build needed 22:10:00, 3349844k disk space

==> gcc-sh-elf_4_amd64-20221211T112240.719Z <==
Build needed 22:08:52, 3349900k disk space

==> gcc-sh-elf_4_amd64-20230121T070646.221Z <==
Build needed 131:59:54, 4206644k disk space

I killed the process by hand in the build logs of 2022-12-11
because I started to see there was something wrong (22 hours
instead of 1-2 hours). That's why they appear as "failed builds".

Then, on 2023-01-21, I decided not to kill the process to
see how long would it really take. And it took 5 days.

The build machines are diverse:

yoda[12] and skywalker[12] are self-hosted virtual machines
using kvm/libvirt, with one CPU and about 6 GB of RAM (enough
for this package according to the data I collected by monitoring
/proc/meminfo during the build).

Machines with names starting with "hh" are Hetzner machines
with 2 CPUs. Machines with names starting with a single "h"
are Hetzner machines with a single CPU.

I can provide ssh access to a Hetzner machine similar to
the ones I used for you to test (please contact me privately
for details).

Thanks.