This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]