public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
To: rth@redhat.com
Cc: dewar@gnat.com, gcc@gcc.gnu.org
Subject: SRA problem with uninitialzed fields
Date: Fri, 24 Sep 2004 16:01:00 -0000	[thread overview]
Message-ID: <10409241406.AA00634@vlsi1.ultra.nyu.edu> (raw)

Robert and I were just talking on the phone about implementation issues of
packed arrays in Ada and I realized there might be a problem with SRA.
Indeed there is and I can show it with a trivial C program. 

Consider:

struct foo {unsigned int f: 2;};

int
sub1 ()
{
  struct foo x;

  x.f |= 3;
  return x.f == 3;
}

SRA makes an x$f and here's the resulting .vars file:

sub1 ()
{
  <unnamed type> x$f;

  return (int) (<unnamed type>) (unsigned char) ((signed char) x$f | 3) == 3;
}

In the original C, the value of x.f is clearly uninitialized, but the
assignment statement forces it to be 3.  So the comparison is always true.

But in the resulting code, x$f is a full byte and so the upper six bits
remain uninitialized.  Thus the comparison above may or not may be true,
depending on how things happened to be initialized.

So clearly this is an unsafe optimization, but it's not clear what the
exact condition for safety is.  I suspect the point is that the SRA'ed
variable can't ever be uninitialized for this to work.

             reply	other threads:[~2004-09-24 14:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-24 16:01 Richard Kenner [this message]
2004-09-24 16:16 ` Andrew Pinski
2004-09-24 16:55 Richard Kenner
2004-09-24 18:23 ` Joseph S. Myers
2004-09-24 18:43 Richard Kenner
2004-09-24 18:50 ` Joseph S. Myers
2004-09-24 18:53 Richard Kenner
2004-09-24 19:02 ` Joseph S. Myers
2004-09-25  2:38   ` Robert Dewar
2004-09-25  2:59     ` Joseph S. Myers

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=10409241406.AA00634@vlsi1.ultra.nyu.edu \
    --to=kenner@vlsi1.ultra.nyu.edu \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rth@redhat.com \
    /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).