Remove the unused EXECUTE_IF_SET_IN_SBITMAP_REV, which has an unconventional
interface.
Rename the sbitmap_iter_* functions to match bitmap's bmp_iter_* functions.
Add an additional parameter to the initialization and next functions to
match the interface in bmp_iter_*. This extra parameter is mostly hidden
by the use of the EXECUTE_IF macros.
Rename the EXECUTE_IF_SET_IN_SBITMAP macro to EXECUTE_IF_SET_IN_BITMAP. Its
implementation is now identical to that in bitmap.h. To prevent redefinition
errors, both definitions are now guarded by #ifndef. An alternate strategy
is to simply include bitmap.h from sbitmap.h. As this would increase build
time, I have elected to use the #ifndef version. I do not have a strong
preference here.
The sbitmap_iterator type is still distinctly named because it is often
declared in contexts where the bitmap type is not obvious. There are less
than 40 uses of this type, so the burden to modify it when changing bitmap
types is not large.
Tested on x86-64, config-list.mk testing.
Index: gcc/ChangeLog
2012-10-31 Lawrence Crowl <crowl@google.com>
* sbitmap.h (sbitmap_iter_init): Rename bmp_iter_set_init and add
unused parameter to match bitmap iterator. Update callers.
(sbitmap_iter_cond): Rename bmp_iter_set. Update callers.
(sbitmap_iter_next): Rename bmp_iter_next and add unused parameter to
match bitmap iterator. Update callers.
(EXECUTE_IF_SET_IN_SBITMAP_REV): Remove unused.
(EXECUTE_IF_SET_IN_SBITMAP): Rename EXECUTE_IF_SET_IN_BITMAP and
adjust to be identical to the definition in bitmap.h. Conditionalize
the definition based on not having been defined. Update callers.
* bitmap.h (EXECUTE_IF_SET_IN_BITMAP): Conditionalize the definition
based on not having been defined. (To match the above.)
From-SVN: r193069
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
Diego Novillo
Lawrence Crowl