This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
- From: "manu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Nov 2007 03:05:49 -0000
- Subject: [Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
- References: <bug-20319-9975@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from manu at gcc dot gnu dot org 2007-11-14 03:05 -------
(In reply to comment #7)
> - yes, the documentation, source code commments and -help are either
> incomplete or do not accurately describe present behavior.
Confirmed. Patches are welcome.
> - -fkepp-static-consts behaves in an unexpected manner, in that when asserted,
> it enables a behavior that is already enabled by default. And interestingly,
> it has no effect when optimization is enabled.
I would argue that it will make sense that -fkeep-static-consts keeps static
consts variables independently of whatever other flags. Then, we could say that
it is enabled by default at -O0 and needs to be specifically enabled at higher
levels.
> - Only -fno-keep-static-consts has an effect, and then only when optimization
> is not enabled.
-fno-keep-static-consts should have the effect of disabling
-fkeep-static-consts, either because it was enabled by default (at -O0) or
because it appeared earlier in the command-line.
> - In general, I think it would be best if switches which selectively control
> optimizations, enable that optimization when asserted, and disable the
> optimization when negatively asserted (ie, when prefixed with no- ...). Thus
> I recommend that -fkeep-static-consts be deprecated, and replaced by a new
> switch, named something like -fdelete-unused-static-consts. It would also be
That sounds good, but deprecating bad names in released versions is bad. The
option is there and there are not many bug reports like these, so it doesn't
seem to be so problematic. Let's fix the above problems first.
> a good idea to look at the other optimization enabling switches to ensure that
> they follow this convention. Ideally, each optimization level such as O1, O2,
> O3, Os, and Ot would be definitively and completely expressed by the selective
> optimization options they enable.
Ot? What is that level supposed to do? Ideally, that sounds good. In practice,
there are too many and too diverse optimizations to warrant particular flags.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-11-14 03:05:49
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319