__attribute__ ((access, ...)) vs __attribute__ ((nonnull))

[David Malcolm <dmalcolm@redhat.com>]

We gained __attribute__ ((access, ...)) in GCC 10:
  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
which identifies one of the pointer/reference arguments of a function
as being accessed according to an access-mode: read_only, read_write,
write_only, or none.

We also have __attribute__ ((nonnull)) to indicate that a function
argument (or all of them) must be non-NULL.

There doesn't seem to be a relationship between these in the
implementation, but it strikes me that almost anywhere that a user
might use the "access" attribute, that parameter is probably going to
be required to be nonnull - though perhaps there are cases where APIs
check for NULL and reject them gracefully?

Might we want to somehow make __attribute__ ((access, ...)) imply
__attribute__ ((nonnull))?  (for non "none" access modes, perhaps?)

If so, one place to implement this might be in tree.cc's
get_nonnull_args, and have it add to the bitmap any arguments that
have an appropriate access attribute.

get_nonnull_args is used in various places:
- validating builtins
- in ranger_cache::block_apply_nonnull
- by -Wnonnull (in pass_post_ipa_warn::execute)
- by -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument;
I'm tracking the failure of these last two to make use of __attribute__
((access)) in PR analyzer/104860.

So do we:

(a) leave it up to the user, requiring them to specify __attribute__
((nonnull)) in addition to  __attribute__ ((access, ...))

(b) leave it up to the individual sites in GCC that currently make use
of get_nonnull_args to add logic for handling   __attribute__ ((access,
...))

(c) extend get_nonnull_args

?

Thoughts?
Dave