From owner-sc22wg5@open-std.org  Thu Dec  4 02:58:33 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 17852C56CF8; Thu,  4 Dec 2008 02:58:33 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107])
	by www2.open-std.org (Postfix) with ESMTP id 2E4E4C4596D
	for <sc22wg5@open-std.org>; Thu,  4 Dec 2008 02:58:31 +0100 (CET)
Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=[127.0.0.1])
	by ns.nag-j.co.jp with esmtp (Exim 4.50)
	id 1L83Tg-0006Dx-7T
	for sc22wg5@open-std.org; Thu, 04 Dec 2008 10:58:04 +0900
Message-ID: <49373984.2060009@nag-j.co.jp>
Date: Thu, 04 Dec 2008 10:59:32 +0900
From: Malcolm Cohen <malcolm@nag-j.co.jp>
User-Agent: Thunderbird 3.0a1pre (Windows/2008022014)
MIME-Version: 1.0
To: sc22wg5 <sc22wg5@open-std.org>
Subject: Re: [ukfortran] (SC22WG5.3710) (j3.2006) Atomic stuff
References: <20081203025222.12F4BC178E0@www2.open-std.org> <20081203174656.5AF23C4596D@www2.open-std.org>
In-Reply-To: <20081203174656.5AF23C4596D@www2.open-std.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@open-std.org
Precedence: bulk



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.

We did, 20 years ago (50 if you count from the beginning).

You are only allowed to change types/kinds in equivalence for the 
type-kind combinations that F77 allowed it for, i.e.
   default int
   default real
   default complex
   default logical
   double precision

as per the quoted Constraints by Nick.  You are not even allowed to 
equivalence double complex with double precision.

Any vendor who allows those as extensions can do whatever they like with 
atomic.

Cheers,
-- 
..........................Malcolm Cohen, Nihon NAG, Tokyo.