http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
Oleg Goldshmidt <pub at goldshmidt dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pub at goldshmidt dot org
--- Comment #10 from Oleg Goldshmidt <pub at goldshmidt dot org> 2011-10-21
20:41:51 UTC ---
Hi,
I recently was bitten by the same "feature" and I would like to add a few
points (important, IMHO) to the discussion.
1. I noticed that combining -g with -O2 kept unused static constants in the
object files up to version 4.4, but not in 4.5 or 4.6. My tests were all done
on Red Hat Linux systems (RHEL or Fedora) rather than on vanilla gcc - I doubt
it matters but I think it needs to be mentioned.
2. I must state that from my prospective the current behaviour is a problem.
There is an optimization that cannot be turned off selectively, even as many
other optimizations can. The behavior of -fkeep-static-consts is illogical, as
others have mentioned.
3. The use case of version control keywords is a very important one. This
thread http://gcc.gnu.org/ml/gcc/2005-04/msg01429.html shows that it is not
regarded as such by the GCC team. I do not intend to start a discussion here,
but with all due respect there are lots of very practical considerations that
may be irrelevant for GCC itself but very relevant in other contexts. I will
only make a general statement as follows:
4. GCC optimizes unused static consts away as it understands that they cannot
be accessed by any program of which the const is a part. It misses the
possibility that the resulting object may be input to another program (e.g.,
ident(1) or strings(1)) and thus there may be a legitimate reason to keep the
const even as other optimizations are applied.
5. I can only regard __attribute__((unused)) as a very poor workaround because
it makes the code non-portable and requires, apart from the definition of the
constant, at least some preprocessor trickery like #ifdef __GNUC__ / #else /
#endif. Dealing with the issue with a compiler option is much better.
This begs for being patched, probably along the lines of what Gary Funck
suggested. I may be willing to look at the code and submit such a patch, but I
would first appreciate a bit of procedural guidance from developers.
This bug, albeit still NEW and unassigned, is against a very old version.
Should a new bug be opened and tracked?
Given that a patch would change the default behaviour of an option, and the
documented "we don't really understand the need for this" opinion (highly
respected but contested), is there a reasonable chance that a patch would be
accepted?
Has a patch like this been submitted and rejected in the past? Verifying it
"from outside" seems a non-trivial task by itself.
Manuel (comment #8)? Anyone? I'd appreciate a reaction before diving in.
Thanks, Oleg.
