Re: [lfs-support] gcc tests
From: William Harrington kb0...@berzerkula.org To: Richard r_j_humphr...@yahoo.co.uk; LFS Support List lfs-support@linuxfromscratch.org ... # of expected passes92870 # of expected failures259 # of unsupported tests1096 ... # of expected passes 92152 # of expected failures 263 # of unsupported tests 1283 ... # of expected passes 93302 # of expected failures 261 # of unsupported tests 1368 Thanks for the info. So, at the risk of sounding irretrievably stupid, why are there differing number of tests for the same source? I could understand two separate builds on different hardware having different numbers of unsupported tests, but I was expecting the totals to still be the same. Unless I have mistyped or my mathematics has completely left me: 92870 + 259 + 1096 = 94225 92152 + 263 + 1283 = 93698 93302 + 261 + 1368 = 94931 I'm struggling to understand why we have differing numbers of tests for the same package. (In fairness, the point is now somewhat moot since I have gone ahead with the install - I am just trying to get a better understanding of things. My reasons for attempting LFS are as much educational as practical.) Again, many thanks, R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Nov 1, 2013, at 5:01 AM, Richard wrote: I'm struggling to understand why we have differing numbers of tests for the same package. you will se some major differences between clfs and lfs because graphite tests are ran with our builds. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] gcc tests
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) 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? Again, many thanks, R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 01:28:09PM +, 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 passes92903 # 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 match. Mostly, I only look at the errors reported by this sort of testsuite. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
From: Ken Moffat zarniwh...@ntlworld.com ... Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 then I have no data to offer. ... I am (I hope!) using the plain, normal, generic, unadulterated LFS 7.4 - which means that I just compiled gcc 4.8.1. I will proceed under the assumption that all is well. Thanks, R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 03:26:35PM +, Richard wrote: From: Ken Moffat zarniwh...@ntlworld.com ... Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 then I have no data to offer. ... I am (I hope!) using the plain, normal, generic, unadulterated LFS 7.4 - which means that I just compiled gcc 4.8.1. I will proceed under the assumption that all is well. Thanks, R. I thought you were using that - clearly, the tests cannot have changed in the past x weeks because the tarball (and its md5sum) has not changed. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Oct 31, 2013, at 8:28 AM, Richard wrote: 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) 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 I looked at the CLFS build I did for our last release of 2.1.0 which used gcc-4.8.1 with a branch update patch right before release and this is my summary and the test above passed. Although my host was a debian jessie system at the time: Running /sources/gcc-4.8.1/gcc/testsuite/gcc.dg/asan/asan.exp ... That test passed and the summary: === g++ Summary === # of expected passes52135 # of expected failures 290 # of unsupported tests 653 /sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.8.1 (GCC for Cross-LFS 4.8.1.20131001) === gcc tests === Running target unix === gcc Summary === # of expected passes92152 # of expected failures 263 # of unsupported tests 1283 /sources/gcc-build/gcc/xgcc version 4.8.1 (GCC for Cross-LFS 4.8.1.20131001) And for the LFS 7.4 test logs where Running /sources/gcc-4.8.1/gcc/ testsuite/gcc.dg/asan/asan.exp ... passed: === g++ tests === Running target unix === g++ Summary === # of expected passes54027 # of expected failures 290 # of unsupported tests 877 /sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.8.1 (GCC) === gcc tests === Running target unix === gcc Summary === # of expected passes93302 # of expected failures 261 # of unsupported tests 1368 /sources/gcc-build/gcc/xgcc version 4.8.1 (GCC) I did have it fail back in May, but not this time around when I released CLFS 2.1.0. http://lists.cross-lfs.org/pipermail/clfs-dev-cross-lfs.org/2013-May/001371.html Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] GCC tests error
Hi, I tried to install gcc at the chapter 6. After the command: make -k check, I got this error: === libitm Summary === # of expected passes26 # of expected failures3 # of unsupported tests1 make[4]: Leaving directory `/sources/gcc-build/x86_64-unknown-linux-gnu/libitm/testsuite' make[3]: Leaving directory `/sources/gcc-build/x86_64-unknown-linux-gnu/libitm/testsuite' make[3]: Entering directory `/sources/gcc-build/x86_64-unknown-linux-gnu/libitm' true DO=all multi-do # make make[3]: Leaving directory `/sources/gcc-build/x86_64-unknown-linux-gnu/libitm' make[2]: Leaving directory `/sources/gcc-build/x86_64-unknown-linux-gnu/libitm' make[1]: Target `check-target' not remade because of errors. make[1]: Leaving directory `/sources/gcc-build' make: *** [do-check] Error 2 make: Target `check' not remade because of errors. The results of the command ../gcc-4.7.2/contrib/test_summary are attached to this message. I read the book version 7.3 Thanks! Antony cat 'EOF' | LAST_UPDATED: Obtained from SVN: tags/gcc_4_7_2_release revision 191558 Native configuration is x86_64-unknown-linux-gnu === g++ tests === Running target unix ERROR: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final: couldn't compile regular expression pattern: out of memory UNRESOLVED: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final: couldn't compile regular expression pattern: out of memory ERROR: g++.dg/abi/mangle33.C -std=c++11: error executing dg-final: couldn't compile regular expression pattern: out of memory UNRESOLVED: g++.dg/abi/mangle33.C -std=c++11: error executing dg-final: couldn't compile regular expression pattern: out of memory === g++ Summary === # of expected passes48482 # of expected failures 286 # of unresolved testcases 2 # of unsupported tests 555 /sources/gcc-build/gcc/testsuite/g++/../../g++ version 4.7.2 (GCC) === gcc tests === Running target unix XPASS: gcc.dg/inline_3.c (test for excess errors) XPASS: gcc.dg/inline_4.c (test for excess errors) XPASS: gcc.dg/unroll_2.c (test for excess errors) XPASS: gcc.dg/unroll_3.c (test for excess errors) XPASS: gcc.dg/unroll_4.c (test for excess errors) === gcc Summary === # of expected passes85669 # of unexpected successes 5 # of expected failures 258 # of unsupported tests 1241 /sources/gcc-build/gcc/xgcc version 4.7.2 (GCC) === libgomp tests === Running target unix === libgomp Summary === # of expected passes1241 === libitm tests === Running target unix === libitm Summary === # of expected passes26 # of expected failures 3 # of unsupported tests 1 === libmudflap tests === Running target unix FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test ERROR: tcl error sourcing /sources/gcc-4.7.2/libmudflap/testsuite/libmudflap.cth/cthfrags.exp. ERROR: couldn't compile regular expression pattern: out of memory === libmudflap Summary === # of expected passes1255 # of unexpected failures1 === libstdc++ tests === Running target unix FAIL: 22_locale/time_get/get_weekday/char/38081-1.cc execution test FAIL: 22_locale/time_get/get_weekday/char/38081-2.cc execution test === libstdc++ Summary === # of expected passes # of unexpected failures2 # of expected failures 43 # of unsupported tests 153 Compiler version: 4.7.2 (GCC) Platform: x86_64-unknown-linux-gnu configure flags: --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib EOF Mail -s Results for 4.7.2 (GCC) testsuite on x86_64-unknown-linux-gnu gcc-testresu...@gcc.gnu.org mv /sources/gcc-build/./gcc/testsuite/g++/g++.sum /sources/gcc-build/./gcc/testsuite/g++/g++.sum.sent mv /sources/gcc-build/./gcc/testsuite/gcc/gcc.sum /sources/gcc-build/./gcc/testsuite/gcc/gcc.sum.sent mv /sources/gcc-build/./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum /sources/gcc-build/./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum.sent mv /sources/gcc-build/./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum /sources/gcc-build/./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum.sent mv /sources/gcc-build/./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum /sources/gcc-build/./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum.sent mv /sources/gcc-build/./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum /sources/gcc-build/./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum.sent mv /sources/gcc-build/./gcc/testsuite/g++/g++.log
[lfs-support] GCC Tests (LFS 7.2 : Ch. 6.17)
While running the test suite for GCC in Ch. 6.17 I saw the following: /sources/gcc-4.7.1/gcc/testsuite/gcc.c-torture/compile/compile.exp ... WARNING: program timed out. FAIL: gcc.c-torture/compile/pr37669-2.c -0s (test for erros) This is running on a Celeron 550MHz with 160MB RAM, so I'm quite certain that it's simply a processing timeout... Will setting the variable: TIMEOUTFACTOR, as is recommended in the prior Glibc chapter, help to complete this test successfully? I'm unsure of a sane value in my case, any ideas? I am asking because the response time for trial-and-error testing is slow on this particular hardware... Thanks for your help. Nicholas McCurdy mindwarpstud...@aim.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
