Re: Hurd GCC ping

[Thomas Schwinge]

Hi!

Matthias Klose has recently re-enable the GCC testsuite for GNU/Hurd, and
while it now runs to completion (hooray!) there are a number of
unexpected test failures (search for »FAIL:«):

On Fri, 15 Aug 2014 14:32:01 +0200, Matthias Klose <doko@ubuntu.com> wrote:
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=hurd-i386&ver=20140814-1&stamp=1408093330

I once began analyzing this.  After one system upgrade, many months ago
(exact timing lost; hardware failure, system set up again, etc.), most of
these FAILs suddenly appeared (especially those testing the basic
functionality of GCC, which he rightly considered worrying).  When
running the FAILing test cases manually, there are no failures.  What
strikes out is that often it's only the later checks for warnings/errors
of one test case that FAIL (where the previous ones have PASSed), and I
think I concluded that GCC's output on stdout gets truncated once it's
reached a limit of 1 KiB of data (or similar) -- but only if running the
testing through »make check«, DejaGnu (runtest), and not when running GCC
(xgcc) manually, where everything works fine.  Also. I got different
results whether I was running in a screen session or not, and/or when I
had been running the testsuite and/or a screen session on the same PTY
before, or a fresh one.  (To sum it up: a mess to diagnose.)

It may be something "simple" like the SA_RESTART bug we recently fixed in
dash: maybe something similar to that in GCC, or DejaGnu (runtest,
expect, TCL), or screen, or something "funny" happening in the Hurd's PTY
machinery (or FIFO?)...

I'm now leaving for vacation, so won't be able to continue with this in
the next weeks, but still have it on my plate for afterwards.

To sum up: there is an issue (regression) in GCC testing, but it should
not cause issues with "real-world" GCC usage.


Grüße,
 Thomas

pgpB10DZMmQP6.pgp
Description: PGP signature