[lfs-support] gcc tests

Ken Moffat zarniwhoop at ntlworld.com
Thu Oct 31 08:07:08 PDT 2013

On Thu, Oct 31, 2013 at 01:28:09PM +0000, Richard wrote:
> Hello again,
> I have finally completed the leviathan task of my first gcc compilation and test.
> I am encouraged to have only one unexpected failure outside libmudflap.
> This leaves me with two questions.
> 1. How bad is that error? I have inferred that it is probably infrequent - but it does no harm to check...
> (FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_HugeMallocTest Ident((char*)malloc(size))[-1] = 0 output pattern test, should match is located 1 bytes to the left of 2726297600-byte)

 I've never seen that one, I assume it is probably platform-specific

 My rule of thumb is that a large number of unexpected failures mean
something is wrong [ I had that once, in the early days of udev ].
Beyond that, I don't have a high regard for testsuites - what really
matters is whether the package will work in normal situations.

 Getting a new failure is interesting, but might be random.

> 2. Far more worryingly - have I somehow mishandled the tests? I am drawn to startling disparity in the test totals. Here is my gcc summary, based on source tarballs downloaded in the past week or so:
> === gcc Summary ===
> # of expected passes92870
> # of expected failures259
> # of unsupported tests1096
> and here is the corresponding section from http://www.linuxfromscratch.org/lfs/build-logs/stable/core2duo/test-logs/080-gcc (which I believe ran in August):
> === gcc Summary ===
> # of expected passes93302
> # of expected failures261
> # of unsupported tests1368
> Am I correct in thinking that I am missing 706 tests? Has the test suite really shrunk by 700 tests in the past 8 weeks?

 Are you using the 7.4 book or svn ?  If you are using gcc-4.8.2
then I have no data to offer.
> Again, many thanks, R.

 I've only built 32-bit x86 once for LFS-7.4 (on a recent AMD
machine, I think it's an A4).  My results were more like yours than
Bruce's :

                === gcc Summary ===

# of expected passes            92903
# of expected failures          259
# of unsupported tests          1084

 What appears to be changing is the number of unexpected failures.
My build had some variations from the -rc1 book (a patch in automake
which I think got into the release, and eudev instead of udev from
systems), but those are later than the gcc test results.  I also
limit the compatability code in glibc [ --enable-kernel=3.9.0 to
suite my rescue CD ] but I'm guessing the config of the running
kernel might be what has most influence on which tests are
unsupported.  Everything else we've built at this stage should

 Mostly, I only look at the errors reported by this sort of

das eine Mal als Tragödie, dieses Mal als Farce

More information about the lfs-support mailing list