public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "gary at intrepid dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts
Date: Fri, 04 Mar 2005 20:24:00 -0000	[thread overview]
Message-ID: <20050304202420.12399.qmail@sourceware.org> (raw)
In-Reply-To: <20050304170516.20319.gary@intrepid.com>


------- Additional Comments From gary at intrepid dot com  2005-03-04 20:24 -------
"Emit variables declared @code{static const} when optimization isn't turned 
on, even if the variables aren't referenced."

How odd.  I should've checked the docs, but this brief explanation in the
help line made a lot of sense to me.

  -fkeep-static-consts        Emit static const variables even if they are not
                              used

Also, since the constant *was kept* when I compiled _without_ optimization,
the idea of passing a switch telling the compiler to do something that
it seemed to already be doing by default didn't make sense to me.

The comments inside toplev.c say the following:

/* Nonzero means that we should emit static const variables
   regardless of whether or not optimization is turned on.  */ 
                            
int flag_keep_static_consts = 1;


which makes sense to me.  Note that this is the default setting.

So ... coming back to the if statement in toplev.c:

              else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)
                       && (optimize || !flag_keep_static_consts
                           || DECL_ARTIFICIAL (decl)))
                needed = 0;

At present,

If optimize is set, the unused static constant will always be eliminated
and -fkeep-static-consts will have no effect, and there is no way to override
this behavior (except for __attribute__ ((used))). 

This agrees with the documentation, but disagrees with the
comment in the code, and with the spirit of the help message.  It also
doesn't make sense to me that -fkeep-static-consts would be ignored. In
fact, it seems to me that -fkeep-static-consts should override the
optimization setting.  Otherwise, only -fno-keep-static-consts has
any effect and that is only when optimization is not enabled.

I think the behavior of -fkeep-static-consts should be modified so that
setting this switch overrides the optimization level.  Thus, the
documentation would need to be changed as well.  Otherwise, the internal
comments and the help line are wrong.

Regarding the "used" attibute, I thought that I'd tried that, and it
didn't work.  But upon retesting, it does seem to have the desired
effect of keeping the static const around (maybe I specified the "unused"
attribute by mistake in my test).

Note that the "used" attribute is described only under "function attributes"
and not under "variable attributes" in the documentation:

used
This attribute, attached to a function, means that code must be emitted for 
the function even if it appears that the function is not referenced. This is 
useful, for example, when the function is referenced only in inline assembly. 

(see: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-
Attributes.html#Function-Attributes)

It would be helpful if the documentation were updated to describe the
behavior of the `used' attribute when apllied to variables.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319


  parent reply	other threads:[~2005-03-04 20:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-04 17:05 [Bug c/20319] New: " gary at intrepid dot com
2005-03-04 18:29 ` [Bug c/20319] " pinskia at gcc dot gnu dot org
2005-03-04 20:24 ` gary at intrepid dot com [this message]
2005-03-04 20:33 ` pinskia at gcc dot gnu dot org
2005-03-04 20:42 ` joseph at codesourcery dot com
2005-03-04 21:54 ` gary at intrepid dot com
2005-03-18 16:16 ` gary at intrepid dot com
2005-06-20  3:04 ` pinskia at gcc dot gnu dot org
2005-06-20 23:40 ` gary at intrepid dot com
     [not found] <bug-20319-9975@http.gcc.gnu.org/bugzilla/>
2007-11-14  3:06 ` manu at gcc dot gnu dot org
2008-06-23 18:04 ` hans at mesoscopic dot mines dot edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050304202420.12399.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).