https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- As I noted in bug 40883 comment 8, you can detect such issues in target-specific code by building a cross compiler using a native compiler from the same trunk version, and configuring with --enable-werror-always (whether with config-list.mk or otherwise), and because many targets are only built as cross compilers it's necessary to do that to detect and fix issues with such targets that show up as warnings when building GCC. At <https://gcc.gnu.org/ml/gcc/2017-09/msg00258.html> I posted a board file that can be used to disable execution testing when running the testsuite for such a cross compiler. It would indeed be helpful to have some packaged system for running a lot of builds and tests like that, so you can just start it up, go away for a while and come back to a set of all-targets test results (contrib/config-list.mk does that if all you want is to see if the compilers build at all, but you need to have the current trunk native compiler already built to use it), rather than needing to set up your own system for running lots of builds and tests - for issues compiling glibc, build-many-glibcs.py achieves that, so people doing complicated cross-architecture changes in glibc can now readily ensure they at least don't break the build for any architecture. Something to discuss at the Cauldron?
