Another question cropping up for me is: what are the testing requirements for a patch of that nature? The final list of files touched in gcc/config/ is:
M alpha/linux.h M alpha/alpha.h M alpha/osf5.h M alpha/netbsd.h M frv/frv.h M spu/spu-protos.h M spu/spu-c.c M spu/spu.c M spu/spu.h M darwin-c.c M i386/i386.h M i386/cygming.h M i386/netware.h M i386/i386-interix.h M i386/i386-c.c M i386/i386-protos.h M i386/nto.h M i386/i386.c M sol2.h M avr/avr.c M avr/t-avr D avr/avr-c.c M avr/avr.h M ia64/hpux.h M rs6000/rs6000-c.c M rs6000/rs6000.c M rs6000/rs6000.h M darwin.c M darwin.h M pa/pa-hpux.h M pa/pa-hpux10.h M pa/pa-hpux11.h M pa/pa.h M mips/linux.h M mips/iris6.h but most are pretty mechanical changes (find all the TARGET_*_CPP_BUILTINS macros that use C-only flags and move then to a separate *_CFAMILY macro). However, of course, breakage could also come from code that I haven't spotted and changed, while I should have. I've done the process twice at a few days' interval, and checking whether the "files to change" list I had come up with was the same, but it's pretty tedious job. So, I can bootstrap and regtested this on i686-linux, x86_64-linux, and x86_64-darwin. Other platforms, I don't have access to or have trouble bootstrapping at all (mingw, I'm looking at you!). My question, thus is: what testing is required for this? Also of interest is: how to get this reviewed and approved? My current plan is: 1. find a global reviewer to do the job (as waiting for individual maintainers to respond might take forever), and 2. make a broad announcement on gcc-patches with a list of targets modified, and give their maintainers a week to speak up if they have remarks. Is that enough? Is that overkill? Thanks for your insight into these issues! FX
