From owner-sc22wg5@open-std.org Fri Dec 5 03:50:13 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 71820CA5FE7; Fri, 5 Dec 2008 03:50:13 +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 B23C8C178DC for ; Fri, 5 Dec 2008 03:50:10 +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 1L8QlC-0003ij-0g for sc22wg5@open-std.org; Fri, 05 Dec 2008 11:49:42 +0900 Message-ID: <49389728.7000605@nag-j.co.jp> Date: Fri, 05 Dec 2008 11:51:20 +0900 From: Malcolm Cohen User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3729) (j3.2006) Atomic stuff References: <20081203025222.12F4BC178E0@www2.open-std.org> <20081203174656.5AF23C4596D@www2.open-std.org> <20081204015833.36905C4596D@www2.open-std.org> <20081204035844.AF831C56CF8@www2.open-std.org> In-Reply-To: <20081204035844.AF831C56CF8@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: > > > > Any vendor who allows those as extensions can do whatever they like > with > > atomic. > > > Fair. If there weren't any customers requesting this, we wouldn't > have supported it either. Actually I wasn't worried about sequence > statement because I think anyone applying atomic operations on storage > associated entities is clearly out of his mind. > > What I'm really concerned about are structure components. For a > sequence derived type, we don't do any padding and it becomes > equivalent to a C struct in pack mode. Well, don't do that for atomic kind then. No-one is forcing anyone to do anything impossible here. If atomic accesses have to be 32-bits and aligned to prime number addresses greater than 2**32, just set INT_ATOMIC_KIND or whatever it's called to 666 and have kind 666 do that. No-one says that INT_ATOMIC_KIND has to be default integer. There's no problem in the standard having multiple kinds with the same precision (but different other characteristics as desired). This is not nontrivial. > It seems to me that we can fix this by putting a sentence in the > description of argument ATOM in ATOMIC_DEFINE and ATOMIC_REF that it > can not be a subobject of sequence type or a derived type with BIND > attribute. Totally unnecessary and horrible, just "do it right". If C/Posix can do sig_atomic_t (and it can, and IBM can too) so can we (in this case the C compiler is *not* at liberty to destroy the semantics). Let's not make mountains out of imaginary molehills. (And if the C compiler doesn't support sig_atomic_t then there won't be a corresponding kind that interoperates, so there is no problem even with non-conforming C compilers.) Cheers, -- .....................Malcolm Cohen, Nihon NAG, Tokyo.