tightening RTL flag checks

[Janis Johnson <janis187 at us dot ibm dot com>]

Some of the RTL flag checking macros allow questionable usages of RTL
codes, but they are included because without them there was a failure
somewhere.  Finding where these are used is straightforward, but fixing
them requires a good understanding of GCC internals and, in some cases,
history, as shown by the current discussion of MEM with REG_POINTER.
The whole point of the flag checks is to find out where flags are used
incorrectly, so we should continue to tighten them up; who knows, maybe
that will lead to changes that fix mysterious bugs.

In http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00597.html,
Richard Henderson questioned several uses.  If I track down where those
are used, what's the best way to report them so someone more
knowledgeable will investigate them further?  Should I file a PR in
GNATS for each one?  I could start discussions by filing a patch for
each one that removes the code from the access macro and then skips use
of the access macro for that code ;-)

As an example, Richard said that INSN_LIST probably shouldn't be used
with RTX_INTEGRATED_P.  On i686-pc-linux-gnu this is used in a single
location, function priority at haifa-sched.c:813.  Is it expected that
an INSN_DEPEND list would include an INSN_LIST?

Janis