Bug 51971 - unclear/unverified restrictions on attribute((const|pure))
Summary: unclear/unverified restrictions on attribute((const|pure))
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.6.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: documentation
Depends on:
Reported: 2012-01-23 17:26 UTC by Akim Demaille
Modified: 2017-07-26 16:15 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:

Declare pure functions which obviously do not return (110 bytes, application/octet-stream)
2012-01-23 17:26 UTC, Akim Demaille

Note You need to log in before you can comment on or make changes to this bug.
Description Akim Demaille 2012-01-23 17:26:28 UTC
Created attachment 26434 [details]
Declare pure functions which obviously do not return


The documentation for const and pure is not clear about the fact that functions should "return normally":

  Interesting non-pure functions are functions with infinite loops or those depending on volatile memory or other system resource, that may change between two consecutive calls (such as feof in a multithreading environment).

In particular, at that point nothing is said about abort().

This is something which does appear in the documentation of -Wsuggest-attribute, yet at that point it is still unclear (to me?):

  The compiler only warns for functions
  visible in other compilation units or (in the case of pure and
  const) if it cannot prove that the function returns normally.

It does not say "do not flag as pure if the function does not return normally".  It does not tell either how to silence the suggestion if the function is not pure.

The warning itself is clearer though:

  akim@boss ~/src/gcc $ g++-mp-4.6 -O2 -Wsuggest-attribute=pure -c gcc/testsuite/gcc.dg/pure-2.c
  gcc/testsuite/gcc.dg/pure-2.c: In function 'int foo3(int)':
  gcc/testsuite/gcc.dg/pure-2.c:38:1: warning: function might be candidate for attribute 'pure' if it is known to return normally [-Wsuggest-attribute=pure]

I think that the documentation should also unveil why there is this restriction.  The documentation for "pure" mentions:

  Such a function can be subject to common subexpression elimination and loop optimization just as an arithmetic operator would be.

It also rules out every use of assert, which is a serious limitation, even for pure functions.

Does that mean that the function might be called _because_ of the optimization?  In which case, yes, indeed, looping or aborting becomes a problem :)  Can CSE really introduce extraneous calls?  The doc does not say so (it says "fewer", not "more"):

  For example,
         int square (int) __attribute__ ((pure));
  says that the hypothetical function square is safe to call fewer times than the program says.

Finally, if really "non-normally returning functions" are ruled out, then GCC should diagnose misuses, such as the attached one.

akim@padam /tmp $ gcc-mp-4.6 -O2 -Wall -Wextra -Wsuggest-attribute=pure -Wsuggest-attribute=const -c /tmp/pure.c
akim@padam /tmp $ echo $?

akim@padam /tmp $ gcc-mp-4.6 --version
gcc-mp-4.6 (GCC) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
Comment 1 Richard Biener 2012-01-24 13:01:03 UTC
GCC explicitely allows you to use const/pure to enable CSE even if it would
not consider the function const/pure itself (thus, if you are happy to
loose a second assert (), or a debug printf).

About returning normally it wants to exclude side-effects that happen
via the return, such as if the function calls longjmp/fork (return twice).
It also wants to exclude functions that do not return because they loop
infinitely.  For example

int foo (int b)
  if (b) while (1);
  return b;

is not const, as GCC would, if you declare it so, happily remove

  foo (1);

as dead code (GCC will do so for all pure/const functions if the result
is not needed).
Comment 2 Eric Gallager 2017-07-26 16:15:40 UTC
Related: bug 18487. They seem different enough to leave as separate bugs though.