gcc/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail

99 lines
7.3 KiB
Plaintext
Raw Normal View History

FAIL: g++.dg/torture/pr46154.C -O3 -fomit-frame-pointer (internal compiler error)
FAIL: g++.dg/torture/pr46154.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
FAIL: g++.dg/torture/pr46154.C -O3 -g (internal compiler error)
FAIL: g++.dg/torture/pr46154.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: g++.dg/torture/pr46154.C -O3 -g (test for excess errors)
FAIL: g++.dg/torture/pr46154.C -O3 -fomit-frame-pointer (test for excess errors)
FAIL: g++.dg/torture/pr46154.C -O2 (test for excess errors)
FAIL: g++.dg/torture/pr46154.C -O2 (internal compiler error)
FAIL: g++.dg/tree-ssa/pr45453.C -std=gnu++98 (test for excess errors)
UNRESOLVED: g++.dg/tree-ssa/pr45453.C -std=gnu++11 scan-tree-dump-times optimized "OBJ_TYPE_REF" 1
UNRESOLVED: g++.dg/tree-ssa/pr45453.C -std=gnu++98 scan-tree-dump-times optimized "OBJ_TYPE_REF" 1
FAIL: g++.dg/tree-ssa/pr45453.C -std=gnu++11 (test for excess errors)
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable
FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times optimized "loopfn" 0
FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 0
FAIL: gcc.dg/builtin-object-size-8.c execution test
FAIL: gcc.dg/graphite/pr42521.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42521.c (test for excess errors)
FAIL: gcc.dg/graphite/pr42771.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42771.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
XPASS: gcc.dg/guality/example.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
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
XPASS: gcc.dg/guality/guality.c -O1 execution test
XPASS: gcc.dg/guality/guality.c -O0 execution test
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
XPASS: gcc.dg/guality/guality.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/inline-params.c -O2 execution test
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 -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
XPASS: gcc.dg/guality/pr41447-1.c -O3 -fomit-frame-pointer execution test
XPASS: gcc.dg/guality/pr41447-1.c -Os execution test
XPASS: gcc.dg/guality/pr41447-1.c -O2 execution test
XPASS: gcc.dg/guality/pr41447-1.c -O3 -g execution test
XPASS: gcc.dg/guality/pr41447-1.c -O0 execution test
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
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 -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
XPASS: gcc.dg/guality/pr41616-1.c -O2 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 -O3 -g 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/inline_3.c (test for excess errors)
XPASS: gcc.dg/inline_4.c (test for excess errors)
FAIL: gcc.dg/pr44974.c scan-assembler call[^\n]*_Exit
FAIL: gcc.dg/torture/pr51106-2.c -Os (test for excess errors)
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 -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 (internal compiler error)
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 -O1 (internal compiler error)
FAIL: gcc.dg/torture/pr51106-2.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr51106-2.c -O0 (internal compiler error)
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)
XPASS: gfortran.dg/do_1.f90 -O0 execution test
XPASS: gfortran.dg/do_1.f90 -O1 execution test
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)
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
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 -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 -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 -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 -fuse-linker-plugin -fno-fat-lto-objects
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: 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: libmudflap.c/fail37-frag.c (-O3) output pattern test
FAIL: libmudflap.c/fail37-frag.c (-O2) output pattern test
FAIL: libmudflap.c/fail37-frag.c (-O3) crash test
FAIL: libmudflap.c/fail37-frag.c (-O2) crash test
FAIL: reflect
FAIL: sourcelocation -findirect-dispatch output - source compiled test
FAIL: sourcelocation -O3 output - source compiled test
FAIL: sourcelocation output - source compiled test