From owner-sc22wg5@open-std.org  Wed Dec  3 19:14:54 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 5E638C56CF8; Wed,  3 Dec 2008 19:14:54 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131])
	by www2.open-std.org (Postfix) with ESMTP id D8847C4596D
	for <sc22wg5@open-std.org>; Wed,  3 Dec 2008 19:14:53 +0100 (CET)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47364)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:nmm1) id 1L7wFQ-0001HT-5y (Exim 4.70) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Wed, 03 Dec 2008 18:14:52 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk)
	with local (PRAYER:nmm1) id 1L7wFQ-0002Pj-Qz (Exim 4.67) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Wed, 03 Dec 2008 18:14:52 +0000
Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk
	with HTTP (Prayer-1.3.1); 03 Dec 2008 18:14:52 +0000
Date: 03 Dec 2008 18:14:52 +0000
From: "N.M. Maclaren" <nmm1@cam.ac.uk>
To: sc22wg5 <sc22wg5@open-std.org>
Subject: Re: [ukfortran] (SC22WG5.3710) (j3.2006) Atomic stuff
Message-ID: <Prayer.1.3.1.0812031814520.6705@hermes-1.csi.cam.ac.uk>
In-Reply-To: <20081203174656.5AF23C4596D@www2.open-std.org>
References: <20081203025222.12F4BC178E0@www2.open-std.org>
 <20081203174656.5AF23C4596D@www2.open-std.org>
X-Mailer: Prayer v1.3.1
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

On Dec 3 2008, Jim Xia wrote:
>
>Now I take another look at the atomic stuff we worked out in Tokyo, I 
>think there is an issue we didn't address: alignment.  Consider on a 
>system we have atomic_integer_kind being 4 bytes, and the processor also 
>supports 2 byte integers, then the following declarations
>
>    integer(2) x(3)
>    integer(ATOMIC_INTEGER_KIND) y, z
>
>    equivalence (y, x(2))
>    equivalence (z, x)
>
>Now either y or z is out of natural alignment.  This will certainly cause 
>implementation problems on atomic operations on y and z.  We have to 
>disallow this to happen.

Already done for that example - see Note 5.42 in 5.7.1.5. But let's say 
that we make the appropriate changes to avoid that. Then it is clobbered by 
constraint C589, C590, C591 and 4.5.2.3.

The problem has been there since time immemorial in the case of systems 
where unaligned access is not supported (especially for DOUBLE PRECISION). 
Yes, I know that the IBM System/360 (sic) Fortran library trapped the 
interrupts and fixed up the alignment, but that was a performance disaster, 
not all compilers did and some still don't. But, curiously, I can't find 
where that that one is locked out.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679