This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Removing useless/redundant "const" calls
- From: Michael Matz <matz at suse dot de>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: law at redhat dot com, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 12 Jun 2003 20:32:36 +0200 (CEST)
- Subject: Re: [tree-ssa] Removing useless/redundant "const" calls
Hi,
On Thu, 12 Jun 2003, Zack Weinberg wrote:
> This seems like an opportune moment to point out that calls to noreturn
> functions shouldn't count as side effects when determining whether
> functions are pure or const.
Careful. For instance also throw() is basically a noreturn function. Is
a function containing a throw free from side-effects? I.e. is
unpredictable control flow change a side-effect or not? We can define it
this or that way, and either one would be arguably correct. We should
define it to be least surprising. For instance:
int get_me (int i) {
if (i < 0)
throw("worked");
return i + 1;
}
void f (void) {
try {
get_me (-1);
} catch (char *p) {
printf ("%s\n", p);
}
}
Per you definition get_me() would be recognized as pure (even as const!),
and hence the call to it in f() would be optimized away. (Not using the
return value of pure functions is one of the only two reasons to delete a
call to them).
I think that's not really expected, as normally the expection will occur.
This leads me to the opinion, that unpredictable control flow change _is_
a side-effect, and functions containing such are not pure. This includes
calls to abort().
It's not that we would gain much from marking such functions pure
automatically (they will be optimized away not that often). But what
could be done instead is to allow the user to explicitely define functions
as pure (per attribute), _even_ if it contains calls to non-pure noreturn
functions. So I'm just against detecting such functions automatically as
pure.
Ciao,
Michael.