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 <d...@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
pgpL4ZQMbsUh1.pgp
Description: PGP signature
