https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97364

            Bug ID: 97364
           Summary: Clarify/improve documentation for __attribute__
                    ((pure))
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: m...@nieper-wisskirchen.de
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The documentation of the `pure' function attribute currently says: "Calls to
functions that have no observable effects on the state of the program other
than to return a value may lend themselves to optimizations such as common
subexpression elimination. Declaring such functions with the pure attribute
allows GCC to avoid emitting some calls in repeated invocations of the function
with the same argument values.

The pure attribute prohibits a function from modifying the state of the program
that is observable by means other than inspecting the function’s return value.
However, functions declared with the pure attribute can safely read any
non-volatile objects, and modify the value of objects in a way that does not
affect their return value or the observable state of the program."

Unfortunately, the documentation is silent on the issue of a function possibly
not returning at all (say, due to an assert macro checking the function
arguments). For example, GCC currently suggest to add the `pure' function
attribute to the function `gl_linked_iterator_from_to' ([1]) of Gnulib. To me,
this seems correct despite the call to `abort', but it is not completely clear
from the wording of GCC's documentation.

Gnulib doesn't want to silence the warning from -Wsuggest-attribute=pure by
adding the `pure' attribute by hand without being sure that it would be indeed
correct.

Which also leads to the question: How to silence the warning in case the
function is *not* pure?

Thanks,

Marc

--

[1]
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/gl_anylinked_list2.h#n938

Reply via email to