From owner-sc22wg5@open-std.org Thu Dec 4 04:58:44 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 91203CA5FE7; Thu, 4 Dec 2008 04:58:44 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by www2.open-std.org (Postfix) with ESMTP id D9D4FC56CF8 for ; Thu, 4 Dec 2008 04:58:43 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB43wCPE006938 for ; Wed, 3 Dec 2008 22:58:12 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB43wggc187604 for ; Wed, 3 Dec 2008 22:58:42 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB43wfxi015376 for ; Wed, 3 Dec 2008 22:58:42 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB43wf41015373 for ; Wed, 3 Dec 2008 22:58:41 -0500 In-Reply-To: <20081204015833.36905C4596D@www2.open-std.org> References: <20081203025222.12F4BC178E0@www2.open-std.org> <20081203174656.5AF23C4596D@www2.open-std.org> <20081204015833.36905C4596D@www2.open-std.org> To: sc22wg5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3727) [ukfortran] Atomic stuff X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 3 Dec 2008 22:58:40 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/03/2008 22:58:41, Serialize complete at 12/03/2008 22:58:41 Content-Type: multipart/alternative; boundary="=_alternative 0015D9D185257515_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0015D9D185257515_= Content-Type: text/plain; charset="US-ASCII" > 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. So its elements can easily be out of natural alignments. I would expect this could be a fairly common implementation on sequence types (or a user defined type rather than an intrinsic type) way back before Fortran 90 came around. Another potential problem is a derived type with BIND attribute. If the companion C processor requires structures to be in packed mode, then the derived type in Fortran side will also be without any alignment. That too will cause trouble for atomic operations. 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. Cheers, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM --=_alternative 0015D9D185257515_= Content-Type: text/html; charset="US-ASCII"

> 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.  So its elements can easily be out of natural alignments.  I would expect this could be a fairly common implementation on sequence types (or a user defined type rather than an intrinsic type) way back before Fortran 90 came around.  Another potential problem is a derived type with BIND attribute.  If the companion C processor requires structures to be in packed mode, then the derived type in Fortran side will also be without any alignment.  That too will cause trouble for atomic operations.

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.

Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM
--=_alternative 0015D9D185257515_=--