From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11040 invoked by alias); 19 Nov 2002 14:36:12 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 11017 invoked by uid 71); 19 Nov 2002 14:36:10 -0000 Date: Mon, 25 Nov 2002 14:55:00 -0000 Message-ID: <20021119143610.11011.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: RE: c++/8543: bus error with 2 word alignments Reply-To: Wolfgang Bangerth X-SW-Source: 2002-11/txt/msg00950.txt.bz2 List-Id: The following reply was made to PR c++/8543; it has been noted by GNATS. From: Wolfgang Bangerth To: gcc-gnats@gcc.gnu.org Cc: Subject: RE: c++/8543: bus error with 2 word alignments Date: Tue, 19 Nov 2002 08:38:31 -0600 (CST) ---------- Forwarded message ---------- Date: Tue, 19 Nov 2002 09:35:42 +0100 From: Massimo Ravasi To: bangerth@dealii.org Subject: RE: c++/8543: bus error with 2 word alignments > -----Original Message----- > From: bangerth@dealii.org [mailto:bangerth@dealii.org] > Sent: Monday, 18 November 2002 19:12 > To: gcc-bugs@gcc.gnu.org; gcc-prs@gcc.gnu.org; ravasi; > nobody@gcc.gnu.org > Subject: Re: c++/8543: bus error with 2 word alignments > > > Synopsis: bus error with 2 word alignments > > State-Changed-From-To: open->analyzed > State-Changed-By: bangerth > State-Changed-When: Mon Nov 18 10:11:12 2002 > State-Changed-Why: > I can confirm this. However, from my limited understanding, > what you do is not legal. You try something like > long long i; > long long *p = (long long *)((char*)&i + 4); > *p = 0; > As far as I can tell, trying to play games with pointers > and not obeying to the alignment rules of the types they > point to is invoking undefined behavior, and a bus error > is undefined behavior. > > That you get varying results with various flags and other > parts of code is to be expected then (after all, a working > program is a valid interpretation of "undefined behavior"). Thank you for you answer, my problem is that I have to deal with long long data which are not guaranteed to be aligned at a 8-byte aligned (but that are guaranteed to be aligned at a 4-byte address... At least. It's an array of bytes where data are stored in a proprietary format) My doubt was if this had to be considered a compiler bug or not, given the non deterministic behavior of the compiled code in the different cases. In any case, comparing long long type to double type, both of them being 8 byte long, I think that an option for long longs like the following one for doubles could be useful in some cases... At least in mine ;-) -munaligned-doubles Assume that doubles have 8 byte alignment. This is the default. With -munaligned-doubles, GCC assumes that doubles have 8 byte alignment only if they are contained in another type, or if they have an absolute address. Otherwise, it assumes they have 4 byte alignment. Specifying this option avoids some rare compatibility problems with code generated by other compilers. It is not the default because it results in a performance loss, especially for floating point code. By the way, is there a reason why such an option is available for SPARC architectures only? That is, what kind of behavior should I expect, or shouldn't I expect, when facing the same problem on another architecture? Bye, Massimo