public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Zack Weinberg <zack@rabi.columbia.edu>
Cc: Joern Rennecke <amylaar@cygnus.co.uk>, egcs@egcs.cygnus.com
Subject: Re: Uninitialized variable warnings
Date: Sun, 28 Mar 1999 00:13:00 -0000	[thread overview]
Message-ID: <2860.922608140@upchuck> (raw)
In-Reply-To: <199903160417.XAA29108@blastula.phys.columbia.edu>

  In message < 199903160417.XAA29108@blastula.phys.columbia.edu >you write:
  > >This is pretty straightforward setting hi in both arms of an if-else
  > >or even unconditionally in each of the disjoint lifetimes.
  > 
  >     case ADDR_EXPR:
  >       {
  >         struct addr_const value;
  > 
  >         decode_addr_const (exp, &value);
  >         if (GET_CODE (value.base) == SYMBOL_REF)
  >           {
  >             /* Don't hash the address of the SYMBOL_REF;
  >                only use the offset and the symbol name.  */
  >             hi = value.offset;
  >             p = XSTR (value.base, 0);
  >             for (i = 0; p[i] != 0; i++)
  >               hi = ((hi * 613) + (unsigned) (p[i]));
  >           }
  >         else if (GET_CODE (value.base) == LABEL_REF)
  >           hi = value.offset + CODE_LABEL_NUMBER (XEXP (value.base, 0)) * 13
  > ;
  > 
  > 	hi &= (1 << HASHBITS) - 1;
  > 
  > If GET_CODE (value.base) is not SYMBOL_REF or LABEL_REF, hi is used
  > unintialized.  Maybe that never happens with correct RTL, but we ought
  > at least to have an `else abort()' in there.  I considered all the
  > cases like this to be real bugs.
Adding an else abort () seems quite reasonable to me.  If it ever triggers
we've got a real bug to track down.

These are precisely the kinds of things we need to spend time looking at --
no -W flag will ever know enough about the semantics of this code to determine
whether or not the variable can be used without being set.

jeff

WARNING: multiple messages have this Message-ID
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Zack Weinberg <zack@rabi.columbia.edu>
Cc: Joern Rennecke <amylaar@cygnus.co.uk>, egcs@egcs.cygnus.com
Subject: Re: Uninitialized variable warnings
Date: Wed, 31 Mar 1999 23:46:00 -0000	[thread overview]
Message-ID: <2860.922608140@upchuck> (raw)
Message-ID: <19990331234600.-dKaPJoqBXuexBzEmmVPVqS3Z2a5dt55Wbq_zw1H1LI@z> (raw)
In-Reply-To: <199903160417.XAA29108@blastula.phys.columbia.edu>

  In message < 199903160417.XAA29108@blastula.phys.columbia.edu >you write:
  > >This is pretty straightforward setting hi in both arms of an if-else
  > >or even unconditionally in each of the disjoint lifetimes.
  > 
  >     case ADDR_EXPR:
  >       {
  >         struct addr_const value;
  > 
  >         decode_addr_const (exp, &value);
  >         if (GET_CODE (value.base) == SYMBOL_REF)
  >           {
  >             /* Don't hash the address of the SYMBOL_REF;
  >                only use the offset and the symbol name.  */
  >             hi = value.offset;
  >             p = XSTR (value.base, 0);
  >             for (i = 0; p[i] != 0; i++)
  >               hi = ((hi * 613) + (unsigned) (p[i]));
  >           }
  >         else if (GET_CODE (value.base) == LABEL_REF)
  >           hi = value.offset + CODE_LABEL_NUMBER (XEXP (value.base, 0)) * 13
  > ;
  > 
  > 	hi &= (1 << HASHBITS) - 1;
  > 
  > If GET_CODE (value.base) is not SYMBOL_REF or LABEL_REF, hi is used
  > unintialized.  Maybe that never happens with correct RTL, but we ought
  > at least to have an `else abort()' in there.  I considered all the
  > cases like this to be real bugs.
Adding an else abort () seems quite reasonable to me.  If it ever triggers
we've got a real bug to track down.

These are precisely the kinds of things we need to spend time looking at --
no -W flag will ever know enough about the semantics of this code to determine
whether or not the variable can be used without being set.

jeff

  parent reply	other threads:[~1999-03-28  0:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-14 20:42 Zack Weinberg
     [not found] ` < 199903150442.XAA28837@blastula.phys.columbia.edu >
1999-03-15  2:45   ` craig
     [not found]     ` < 19990315103933.22049.qmail@deer >
1999-03-15  4:56       ` Zack Weinberg
     [not found]         ` < 199903151256.HAA08065@blastula.phys.columbia.edu >
1999-03-15 13:19           ` craig
     [not found]             ` < 19990315211232.23607.qmail@deer >
1999-03-15 20:03               ` Zack Weinberg
1999-03-31 23:46                 ` Zack Weinberg
1999-03-31 23:46             ` craig
1999-03-31 23:46         ` Zack Weinberg
1999-03-31 23:46     ` craig
1999-03-15 13:28   ` Joern Rennecke
     [not found]     ` < 199903152127.VAA32106@phal.cygnus.co.uk >
1999-03-15 20:21       ` Zack Weinberg
     [not found]         ` < 199903160417.XAA29108@blastula.phys.columbia.edu >
1999-03-16 11:58           ` Joern Rennecke
1999-03-31 23:46             ` Joern Rennecke
1999-03-28  0:13         ` Jeffrey A Law [this message]
1999-03-31 23:46           ` Jeffrey A Law
1999-03-31 23:46         ` Zack Weinberg
1999-03-17 20:38       ` Jeffrey A Law
     [not found]         ` < 14630.921731892@hurl.cygnus.com >
1999-03-18  9:25           ` Zack Weinberg
1999-03-31 23:46             ` Zack Weinberg
1999-03-31 23:46         ` Jeffrey A Law
1999-03-31 23:46     ` Joern Rennecke
1999-03-31 23:46 ` Zack Weinberg
     [not found] <199903162144.QAA19514@blastula.phys.columbia.edu>
1999-03-16 14:08 ` Joern Rennecke
1999-03-31 23:46   ` Joern Rennecke

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=2860.922608140@upchuck \
    --to=law@upchuck.cygnus.com \
    --cc=amylaar@cygnus.co.uk \
    --cc=egcs@egcs.cygnus.com \
    --cc=zack@rabi.columbia.edu \
    /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).