From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7208 invoked by alias); 24 Sep 2004 16:19:59 -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 7198 invoked from network); 24 Sep 2004 16:19:58 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 24 Sep 2004 16:19:58 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA01865; Fri, 24 Sep 04 12:23:18 EDT Date: Fri, 24 Sep 2004 18:53:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10409241623.AA01865@vlsi1.ultra.nyu.edu> To: jsm@polyomino.org.uk Subject: Re: SRA problem with uninitialzed fields Cc: gcc@gcc.gnu.org X-SW-Source: 2004-09/txt/msg01433.txt.bz2 A proper implementation that keeps the types those that accord with the language semantics would be for the GIMPLE generated to include explicit mask operations for assignments to bit-fields. If it doesn't represent that assignment to a bit-field from the same type may change the value, then there are likely to be problems. At one point there were, but I don't see such problems at present in some quick tests. Well, look at the test case I sent. A mask is clearly required on the comparison (at least, I think so!), but the only mechanism to generate it is the hook, which is false for C++.