c++/8543: bus error with 2 word alignments

[Wolfgang Bangerth]

The following reply was made to PR c++/8543; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
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 <massimo.ravasi@epfl.ch>
 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