OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
gcc/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail

127 lines
10 KiB
Plaintext
Raw Normal View History

* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/Wstrict-overflow-18.c (test for bogus messages, line 20)
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable
XPASS: gcc.dg/guality/example.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/example.c -O2 execution test
XPASS: gcc.dg/guality/example.c -O0 execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/guality.c -O2 execution test
XPASS: gcc.dg/guality/guality.c -O3 -fomit-frame-pointer execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/guality.c -O1 execution test
XPASS: gcc.dg/guality/guality.c -O0 execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/guality.c -Os execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/guality.c -O3 -g execution test
XPASS: gcc.dg/guality/guality.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
XPASS: gcc.dg/guality/guality.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/inline-params.c -O2 execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/inline-params.c -O3 -g execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/inline-params.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
XPASS: gcc.dg/guality/inline-params.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
XPASS: gcc.dg/guality/inline-params.c -O3 -fomit-frame-pointer execution test
XPASS: gcc.dg/guality/inline-params.c -Os execution test
XPASS: gcc.dg/guality/pr41447-1.c -O1 execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O3 -fomit-frame-pointer execution test
XPASS: gcc.dg/guality/pr41447-1.c -Os execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O2 execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O3 -g execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O0 execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/pr41447-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
XPASS: gcc.dg/guality/pr41616-1.c -O1 execution test
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
XPASS: gcc.dg/guality/pr41616-1.c -O3 -fomit-frame-pointer execution test
XPASS: gcc.dg/guality/pr41616-1.c -O0 execution test
XPASS: gcc.dg/guality/pr41616-1.c -Os execution test
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
XPASS: gcc.dg/guality/pr41616-1.c -O2 execution test
XPASS: gcc.dg/guality/pr41616-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
XPASS: gcc.dg/guality/pr41616-1.c -O3 -g execution test
XPASS: gcc.dg/inline_3.c (test for excess errors)
XPASS: gcc.dg/inline_4.c (test for excess errors)
FAIL: gcc.dg/pr52558-1.c scan-tree-dump-times lim1 "MEM count_lsm.. count_lsm_flag" 1
FAIL: gcc.dg/pr52558-2.c scan-tree-dump-times lim1 "MEM.*g_2_lsm_flag" 1
FAIL: gcc.dg/tm/reg-promotion.c scan-tree-dump-times lim1 "MEM count_lsm.. count_lsm_flag" 1
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
FAIL: gcc.dg/torture/pr51106-2.c -O3 -g (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -Os (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O3 -fomit-frame-pointer (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -Os (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O0 (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O1 (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O2 (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O3 -fomit-frame-pointer (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)
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk. This patch adds an xfail manifest for trunk for x86_64 builds. I find this useful to determine whether my patch has introduced new failures. The failures in these manifest are always present in trunk and deciding what to ignore is not very straightforward. I will keep maintaining this manifest out of clean builds. They are not hard to maintain. Manifest files can be generated by going to the top of the build directory and typing: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management --produce_manifest This will generate a .xfail file with the triple name of the target you just built. Once this file exist you can run the validator again on the build directory with no arguments. It should produce the output: $ cd <top-of-bld-dir> $ <path-to-src>/contrib/testsuite-management/validate_failures.py Source directory: <path-to-src> Build target: x86_64-unknown-linux-gnu Manifest: <path-to-src>/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail Getting actual results from build ./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum ./x86_64-unknown-linux-gnu/libffi/testsuite/libffi.sum ./x86_64-unknown-linux-gnu/libgomp/testsuite/libgomp.sum ./x86_64-unknown-linux-gnu/libgo/libgo.sum ./x86_64-unknown-linux-gnu/boehm-gc/testsuite/boehm-gc.sum ./x86_64-unknown-linux-gnu/libatomic/testsuite/libatomic.sum ./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum ./x86_64-unknown-linux-gnu/libitm/testsuite/libitm.sum ./x86_64-unknown-linux-gnu/libjava/testsuite/libjava.sum ./gcc/testsuite/g++/g++.sum ./gcc/testsuite/gnat/gnat.sum ./gcc/testsuite/ada/acats/acats.sum ./gcc/testsuite/gcc/gcc.sum ./gcc/testsuite/gfortran/gfortran.sum ./gcc/testsuite/obj-c++/obj-c++.sum ./gcc/testsuite/go/go.sum ./gcc/testsuite/objc/objc.sum SUCCESS: No unexpected failures. If the output shows new failures, you investigate them. If they are not yours, you can add them to the xfail manifest (after reporting them) and then commit the modified .xfail file. Long term, I would like to have this script pull manifest files from postings made to gcc-testresults. This way, we won't have to maintain these .xfail files manually. In branches this is not a big problem, but in trunk it may be a tad annoying. From-SVN: r190404
2012-08-15 04:25:19 +02:00
FAIL: gcc.target/i386/pad-10.c scan-assembler-not nop
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update. From-SVN: r190929
2012-09-04 15:23:10 +02:00
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute -O0 -flto -flto-partition=none -fuse-linker-plugin
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o execute -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o execute -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o execute -O0 -flto -flto-partition=none -fuse-linker-plugin
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors)
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -Os compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O1 compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O0 compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O3 -g compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_15.f90 -O2 compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -g (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -g (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -Os compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors)
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O0 compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O2 compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O3 -g compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_2.f03 -Os (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors)
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable
FAIL: gfortran.dg/realloc_on_assign_2.f03 -Os (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error)
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable
UNRESOLVED: gfortran.dg/realloc_on_assign_2.f03 -O1 compilation failed to produce executable
FAIL: gnat.dg/array11.adb (test for warnings, line 12)
FAIL: gnat.dg/object_overflow.adb (test for warnings, line 8)
FAIL: libmudflap.c++/pass55-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass55-frag.cxx (-O3) execution test
FAIL: log