(j3.2006) Urgent: GB39

[john.reid at stfc.ac.uk]

Malcolm,

Thank you for this message. It confirms (but amplifies) what I understood to be your position.

I am copying this to J3 because the paper is to be discussed in plenary this morning. 

Best wishes,

John. 
________________________________________
From: Malcolm Cohen [malcolm at nag-j.co.jp]
Sent: 12 October 2011 01:13
To: Reid, John (STFC,RAL,CSE)
Subject: Re: Urgent: GB39

Hi John,

>Comment GB 39 has provoked much discussion. Here is the latest version with
>alternative edits. We'd appreciate your >opinion.

The alternative is not acceptable.

The F2008 standard permits an implementation to do its discontiguous-contiguous
copying in either place - the caller or the called - at its option.

The TR should not be making changes to the requirements of the Fortran standard
without very good reason.  In making the GB39 comment I assumed there was a good
reason (described below), and the alternative edit breaks that reason.

The alternative paragraph has the worst of both worlds: it makes requirements on
the Fortran processor (it can no longer do the copying solely in the called
routine) without giving the C programmer the convenience enjoyed by Fortran
programmer (passing a discontiguous argument to a contiguous dummy).

The penultimate "non-alternative" paragraph (i.e. the one beginning "In an
invocation") does make requirements on the Fortran processor (it can no longer
do the copying solely in the calling routine) but does give the C programmer the
convenience afore-mentioned.

I understand the desire of some vendors not to have to produce copying code in
the called routine; in that case the solution is to
(a) require the C routine to pass contiguous arguments,
(b) require the C routine to handle discontiguous arguments.
That is a bit less convenient for the C programmer - but then if he was only
prepared to handle contiguous arguments he wouldn't be using the dope vectors,
right? ... he would be using a plain pointer and a size (or maybe a list of
extents, but anyway a dope vector is extreme overkill).

The GB39 comment assumed we wanted to provide the same convenience to the C
programmer in this situation as for the Fortran programmer, and that therefore
we would choose to impose a small burden on the Fortran vendor; that rationale
evaporates if we are not going to do the job properly of making it convenient
for the C programmer.

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

-- 
Scanned by iCritical.