I'm surprised to find it depends on the version of GCC. GCC 2.7.2.3
does _not_ optimise away the branch, but EGCS 1.0.3a does. I don't know
about GCC 2.8.1, as I don't have it installed.
I'm sure it once depended on C vs. C++. C would not optimise the
branch, but C++ would. I recall (mistakenly?) that C++ changed the
semantics of `const' to permit this sort of optimisation, while C had to
allow for `*(int *)&C_FOO = 2'.
Things must have moved on, because now EGCS seems quite willing to
optimise as if C_FOO is constant. This is a good thing.
> One of the things I am fairly certain of wrt gcc is that optimization is
> functionwise, which means that I don't know if globals will be
> considered at all when doing expression reduction.
See above. In C++ they have always been considered; it seems EGCS 1.0.3
at least considers them for C as well.
> If global constants aren't optimized as constants, then #define C_FOO
> 1 is forced upon us. Pity. The int has the advantage of possibly
> raising a warning in the future if used in an #ifdef (by mistake).
Well, there's not much you can do to _warn_ about #ifdef -- it is always
either true or false.
However, you can have a scheme which supports `if (CONFIG_XXX)', `#if
CONFIG_XXX' and `#ifdef CONFIG_XXX' all at the same time:
/* Enabled */
#define C_FOO C_FOO
const int C_FOO = 1;
/* Disabled */
#undef C_BAR
const int C_BAR = 0;
Do you like this? I do, if the compilers will optimise `const int'. As
GCC 2.7.2.3 does _not_ optimise this, this has to be done with or after
a change in the official compiler used.
In fact, I like this so much I might use it in my future programs ;-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/