From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19066 invoked by alias); 4 Aug 2005 12:40:08 -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 18986 invoked by uid 22791); 4 Aug 2005 12:40:01 -0000 Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 04 Aug 2005 12:40:01 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j74CdwZl020962 for ; Thu, 4 Aug 2005 08:39:59 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j74CdsNd020957; Thu, 4 Aug 2005 08:39:57 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 08:39:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17138.3224.786605.462292@gargle.gargle.HOWL> Date: Thu, 04 Aug 2005 12:40:00 -0000 From: Paul Koning To: rth@redhat.com Cc: ian@airs.com, pinskia@physics.uc.edu, mrs@apple.com, dave.korn@artimi.com, gcc@sources.redhat.com, sjackman@gmail.com Subject: Re: memcpy to an unaligned address References: <200508022037.j72Kbr4T012558@earth.phy.uc.edu> <20050803180011.GA16808@redhat.com> X-SW-Source: 2005-08/txt/msg00145.txt.bz2 >>>>> "Richard" == Richard Henderson writes: >> > No it is not, once you take the address (which should be >> rejected), it > is of type "unsigned int *" and not unaligned >> variable, passing it to > memcpy assumes the type alignment is the >> natural alignment. >> >> That argument doesn't make sense to me. Richard> It is nevertheless correct. Examine all of the parts of the Richard> expression. Richard> In particular, "&s->b". What type does it have? In an Richard> ideal world, it would be "pointer to unaligned integer". Richard> But we have no such type in our type system, so it is Richard> "pointer to integer". This expression is ONLY THEN passed Richard> to memcpy. At which point we query the argument for its Richard> alignment, and get the non-intuitive result. The underlying problem is that the type system in GCC isn't right. The C type system has data of various kinds, pointers to them, structures made up of the above, etc. GCC extends the type system by introducing selectable alignment. But it doesn't do it consistently. We have int, we have *int, we have packed int, but we don't have *packed int. So the outcome is "correct" only if you treat GCC's incomplete type system as correct, which I don't agree with. This does mean, unfortunately, that the fix is to correct that incompleteness, which was said to be a nontrivial task. paul