On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote:
> On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc
> <gcc@gcc.gnu.org> wrote:
> >
> > 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?
>
> No, I think they are separate. The access just says these access
> attributes are read only, write only, read-write or don't access what
> the pointer points to; it does not say they have to be read or
> written
> to.
> I think it is a bad idea to connect the two ideas because you could
> have some cases where an argument is optional but is only read from;
> or is only written to (there are many in GCC sources even).
Thanks for the clarification...
>
> Thanks,
> Andrew Pinski
>
> >
> > 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, ...))
...so that's (a) then.
I think it might be more user-friendly to be explicit about this in the
documentation, maybe something like the attached?
(not yet fully tested, but seems to build)
Dave
> >
> > (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
> >
>
From 9dc75031963f01b1711a769b7afcc5c590ce07fd Mon Sep 17 00:00:00 2001
From: David Malcolm <dmalc...@redhat.com>
Date: Wed, 9 Mar 2022 16:52:49 -0500
Subject: [PATCH] Document that the 'access' and 'nonnull' attributes are
independent
gcc/ChangeLog:
* doc/extend.texi (Common Function Attributes): Document that
'access' does not imply 'nonnull'.
Signed-off-by: David Malcolm <dmalc...@redhat.com>
---
gcc/doc/extend.texi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0dc752e8aad..bfa09c0f5bc 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2652,6 +2652,13 @@ The mode is intended to be used as a means to help validate the expected
object size, for example in functions that call @code{__builtin_object_size}.
@xref{Object Size Checking}.
+Note that the @code{access} attribute merely specifies how an object
+referenced by the pointer argument can be accessed; it does not imply that
+an access @strong{will} happen. If the pointer will definitely be
+dereferenced, you may want to also add
+@code{__attribute__((nonnull (@var{arg-index})))} to the function for the
+pointer parameter in question.
+
@item alias ("@var{target}")
@cindex @code{alias} function attribute
The @code{alias} attribute causes the declaration to be emitted as an alias
--
2.26.3
