From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David S. Miller" <davem@dm.cobaltmicro.com>
To: burley@gnu.org
Cc: law@cygnus.com, d.love@dl.ac.uk, egcs@cygnus.com
Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
Date: Tue, 23 Jun 1998 03:32:00 -0000
Message-id: <199806230945.CAA20017@dm.cobaltmicro.com>
References: <199806221829.OAA07477@melange.gnu.org>
X-SW-Source: 1998-06/msg00785.html

   Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT)
   From: Craig Burley <burley@gnu.org>

   A case we can't 64-bit align is:

	   real r(2)
	   double precision d1, d2
	   equivalence (r(1),d1)
	   equivalence (r(2),d2)

   Regardless of whether this is stack, static, or even part of a common
   block, we can't 64-bit align both d1 and d2.  (Well, not without
   an option to completely change the way we implement Fortran; I wonder
   if Sun does that to support weird-but-conforming code on SPARCs,
   such as the above.)

I can give some insight to this on certain cases on the Sparc.

The UltraSparc has specific high performance trap vectors dedicated to
handling the case where a double float load is done to an address
which is not aligned correctly.  The UltraSparc users manual suggests
that if the compiler can determine that the likelyhood of bad
alignment is 50/50 or less, if should output the double float loads.

However there is an OS level side issue to this.  Sparc is rather
strict about unaligned loads by default on most systems I know about.
However, most systems provide some way to tell the OS to "allow
unaligned memory accesses, and fix them up for the program".

This would need some investigation before such a scheme is enable in
egcs, so I'd say defer thinking about it until after the 1.1 release
happens.

Later,
David S. Miller
davem@dm.cobaltmicro.com