public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gawain Bolton <gbolton@free.fr>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: pcarlini@unitus.it, gcc@gcc.gnu.org
Subject: Re: Const warning? (was: Re: [Patch] More redundant...)
Date: Mon, 21 Apr 2003 16:06:00 -0000	[thread overview]
Message-ID: <3EA4009E.4000309@free.fr> (raw)
In-Reply-To: <200304202302.TAA09583@caip.rutgers.edu>

I'm glad to hear that there may already be a patch to have a "const" 
warning!  I can certainly see that pointers to pointers to pointers etc. 
would be more difficult to do, especially since const can be at any level.

To me, it is certainly worth having a warning if it can result in faster 
compile times and/or better code being generated.

As Paolo says, ideally the compiler would be able to generate the same 
code whether variables are marked const or not.  However, this is maybe 
not realistic.  So maybe it would just be a good idea to encourage use 
of const to save the compiler from having to do all the analysis to 
determine that a variable is const.


Gawain

Kaveh R. Ghazi wrote:

> > [discussion moved to gcc]
> > 
> > Gawain Bolton wrote:
> > 
> > 
> > These patches to add "const" make me wonder if the compiler couldn't
> > help us.
> > 
> > I thinking about a warning for variables which the compiler can see
> > are not modified. Something like:
> > 
> > Warning: Variable x should be const.
> > 
> > Is this possible? Could this be useful? 
> > 
> > Hi Gawain (by the way those patches mainly remove some NULL pointer
> > checks, only secondarily const-ify variables).
> > 
> > I find your question interesting: as for many other warnings of this
> > kind (unreachable code, uninitialized variables, and so on) how many
> > such warnings would be missed or spuriously emitted would constitute a
> > good testbed for the optimizers of the compiler. Ideally the code
> > generated would be identical with and without const qualifiers but we
> > all know that in the real world this is not the case!
> > 
> > Ideas from the compiler people???
> > Paolo.
>
>I once toyed with a patch to warn about variables that could be
>constified.  It worked fine for regular objects, but the hard part
>(for me at least) was pointers.  E.g:
>
> > char *****foo;
> > ***foo = bar;
>
>Getting it to understand and mark which of the pointer layers could be
>constified and which couldn't was beyond my abilities.  It's probably
>not hard for someone who understands how these trees are constructed.
>
>Note fixing it for pointers is important for finding large statically
>initialized data and sticking it in .rodata sections.
>
>If someone is interested in carrying this across the goal-line, I can
>try and dig it up.
>
>		--Kaveh
>--
>Kaveh R. Ghazi			ghazi@caip.rutgers.edu
>
>
>  
>


  reply	other threads:[~2003-04-21 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3EA18026.70900@unitus.it>
     [not found] ` <3EA1B709.3060204@free.fr>
2003-04-21  2:21   ` Paolo Carlini
2003-04-21  4:58     ` Kaveh R. Ghazi
2003-04-21 16:06       ` Gawain Bolton [this message]
2003-04-22  0:07 Robert Dewar
2003-04-22  6:52 John Reiser

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=3EA4009E.4000309@free.fr \
    --to=gbolton@free.fr \
    --cc=gcc@gcc.gnu.org \
    --cc=ghazi@caip.rutgers.edu \
    --cc=gp.bolton@computer.org \
    --cc=pcarlini@unitus.it \
    /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).