From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4119 invoked by alias); 10 Apr 2003 22:02:41 -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 4103 invoked from network); 10 Apr 2003 22:02:40 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 10 Apr 2003 22:02:40 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA03559; Thu, 10 Apr 03 18:06:47 EDT Date: Thu, 10 Apr 2003 22:16:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10304102206.AA03559@vlsi1.ultra.nyu.edu> To: dewar@gnat.com Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org X-SW-Source: 2003-04/txt/msg00484.txt.bz2 Wel then there is some other funny behavior, which is that it is widely understood that provinding a confirming rep clause shoud have no effect at all on the generated code. So if it should make no difference to the code whether a confirming rep clause is given, how can it be possbiule in some cases that it should be omitted. No, that's actually OK since it is the property of the macros that modify alignment that if you start with the alignment that they produced, they produce that alignment again. I suppose nobody has even formally documented this property, but it would be very hard to see why they would do anything else.