Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Type: text/plain;
  charset="iso-8859-1"
From: Tim Prince <tprince AT computer DOT org>
Reply-To: tprince AT computer DOT org
To: "Billinghurst, David (CRTS)" <David DOT Billinghurst AT riotinto DOT com>,
   <java AT gcc DOT gnu DOT org>
Subject: Re: Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:
Date: Sun, 5 May 2002 17:18:34 -0700
Cc: <cygwin AT cygwin DOT com>
References: <FAC87D7C874EAB46A847604DA4FD5A6403470E AT crtsmail DOT corp DOT riotinto DOT org>
In-Reply-To: <FAC87D7C874EAB46A847604DA4FD5A6403470E@crtsmail.corp.riotinto.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020506001833.617B12CA87@inet1.ywave.com>

On Sunday 05 May 2002 16:49, Billinghurst, David (CRTS) wrote:
> cygwin readers:  This is about porting java to cygwin for gcc-3.2
> (and perhaps gcc-3.1.1 if the changes are small).
>
> So we need objects to be 8-byte aligned so that the low three bits
> of the address are 0?  Are there any ways around this, as I don't
> think that this is the default on cygwin.
>
> I seem to recall that:
>  - objects are only 4-byte aligned by default.
The binutils alignment parameter in coff-i386.c is set to 4-byte alignment.  
4-byte alignment also is the default for gcc -Os, at least from gcc-3.1.  
Cases have been produced where gcc-3.1 failed to give 16-byte alignment 
even with -O2, unless -mpreferred-stack-boundary=4 was specified.
>  - it is necessary to rebuild ld to ensure 8-byte alignment
not only ld, but all of binutils
>  - there are performance benefits for 8-byte (or even 16-byte)
>    alignment, but arguements against.
8-byte alignment is required for reasonable performance with 64-bit data.  
16-byte alignment is required by <xmmintrin.h>, which uses aligned sse 
instructions, and for reasonable performance with un-aligned sse instructions.
P4 does not share the 16-byte code alignment requirements for full 
performance which P-II/P-III have.

I have been building and testing gcc-3.1 in cygwin with 16-byte alignments 
specified, wherever I know how, with no ill effects, and I consider it a must 
for gcc-3.1.
16-byte alignment is incompatible AFAIK with the libstdc++ of gcc-2.95.x, but 
the C, f77, and objc compilers have no problem with it.
The primary argument I have seen for making 4-byte alignment the default for 
-Os in gcc had to do with the 1MB stack per thread limitation being easily 
exceeded.  Future glibc should always have at least 8MB stack per thread.  I 
don't know the answers for the cygwin environment.
Another argument which has been made in the past is that MSVC couldn't be 
counted upon for better than 4-byte alignments.
>
> There is much discussion over a long period in the cygwin archives,
> which I will obviously have to re-read in the next little while.
>
> -----Original Message-----
> From: Tom Tromey [mailto:tromey AT redhat DOT com]
> Sent: Saturday, 4 May 2002 6:31
> To: Billinghurst, David (CRTS)
> Cc: java AT gcc DOT gnu DOT org
>
> Subject: Re: cygwin failures - assertion "!(addr & FLAGS)" failed:
> >>>>> "David" == Billinghurst, David (CRTS)
> >>>>> <David DOT Billinghurst AT riotinto DOT com> writes:
>
> David> At last a real bug in the cygwin libjava testsuite.  Most of the
> David> compilation tests pass, but all (that I could find) executable
> David> tests fail with
>
> David> assertion "!(addr & FLAGS)" failed: file
> "/usr/local/src/gcc3.1/libjava/java/lang/natObject.cc", line 772
>
> My understanding is that we use the lowest 3 bits to keep some
> information about the thin locks.  If this assertion fails, it means
> that we've found an object which isn't suitably aligned.  I think this
> can mean one of two things:
>
> 1. There is a bug in the allocator (unlikely), or
> 2. The compiler isn't properly aligning an object which it lays out
>    statically.  For instance this could happen with some Class object
>
> A bug along these lines was fixed pretty recently:
>
> 2002-04-18  Bryce McKinlay  <bryce AT waitaki DOT otago DOT ac DOT nz>
>
> 	* class.c (make_class_data): Set DECL_ALIGN on static class data,
> 	for hash synchronization.
> 	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
> 	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
> 	class_type_node.
>
> If you already have this patch then I guess there's another such bug :-(
>
> Tom

-- 
Tim Prince

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/