From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32059 invoked by alias); 24 Sep 2004 14:03:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32044 invoked from network); 24 Sep 2004 14:03:14 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 24 Sep 2004 14:03:14 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA00634; Fri, 24 Sep 04 10:06:34 EDT Date: Fri, 24 Sep 2004 16:01:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10409241406.AA00634@vlsi1.ultra.nyu.edu> To: rth@redhat.com Subject: SRA problem with uninitialzed fields Cc: dewar@gnat.com, gcc@gcc.gnu.org X-SW-Source: 2004-09/txt/msg01425.txt.bz2 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 () { x$f; return (int) () (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.