https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115237
--- Comment #2 from Paul Eggert <eggert at cs dot ucla.edu> ---
(In reply to Richard Biener from comment #1)
> 'pure' means the function has no side-effect besides reading global memory
> _when it returns_, so it's valid to turn
>
> x = unite (5, 6);
> y = unite (5, 6);
>
> into
>
> x = unite (5, 6);
> y = x;
Although that particular optimization is valid, as I understand it pure
functions have an additional constraint: they must return. So, if 'unite' is
pure it's also valid to turn this statement:
unite (5, 6);
into a no-op. For example, when compiled with gcc -O2 -S, this program:
int unite (int, int) __attribute__((pure));
int
main (int argc, char **argv)
{
unite (argc, argc + 1);
}
generates the same machine code as the no-op program 'int main (int argc, char
**argv) {}', because GCC optimizes away the call to 'unite'.
Since this sort of optimization is invalid for calls to the 'unite' function I
gave (which sometimes does not return), 'unite' should not be given the
attribute 'pure'.
